Re: [opensuse-factory] Re: openSUSE flaunting GPL
Bryen M Yunashko 07/15/12 9:20 PM >>> On Sun, 2012-07-15 at 13:14 -0700, Linda Walsh wrote: That I need to develop and debug SuSE's proprietary OBS system to create an unsatisfactory build environment, is less than satisfactory. AFAIK, OBS is not proprietary. It is a tool developed under the openSUSE Project and thus open sourced.
Bryen is correct The Source for OBS is not proprietary, you can find the source here https://github.com/openSUSE/open-build-service And it's GPL-licensed.. If you have any changes Linda, I'm sure the guys behind OBS would be happy to consider them Regards Richard -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Richard Brown wrote:
If you have any changes Linda, I'm sure the guys behind OBS would be happy to consider them
---- Off the top of my head... I can think of one good change to consider. Stop building on empty systems -- they don't represent what any customer has in the field. Install the devel packages and install the desktop and all the devel tools...everything a normal developer would be likely to install on a development system. Make that the base system -- and build packages from there. That way if there are any interactions, you can take action and prune off the problem before it goes into the field. Also building with a full set of packages installed, is alot more likely to uncover other unexpected interactions during the build process... (that shouldn't happen but...sometimes do)... I'd also __like__ for you to keep sources, at least, in separate dirs like you do build dirs, -- i.e -- something like: %_sourcedir %{_topdir}/SOURCES/%{name}-%{version} %_specfile %{_topdir}/SPECS/%{name}-%{version}.spec It doesn't work for for a few products that make assumptions about the location of sources instead of relying on the macros...nor does it work if version is reset in a spec file (i.e. building more than one product with different versions in same spec file).... to work around the latter, I usually reversion the sub-products included in some main produce with it's version -- so they are are tied together with 1 version number... But that's an imperfect solution to bundling separate products with different versions in the same spec file. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, 2012-07-16 at 20:23 -0700, Linda Walsh wrote:
Stop building on empty systems -- they don't represent what any customer has in the field.
Package building in the corporate environment always works on a clean image. That's the way I've done it for years when I was a ZENworks consultant. No customer in their right mind would build packages on dirty images. You would spend 5 times as much time building trying to troubleshoot what on your image made things go wrong. Bryen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Bryen M Yunashko wrote:
On Mon, 2012-07-16 at 20:23 -0700, Linda Walsh wrote:
Stop building on empty systems -- they don't represent what any customer has in the field.
Package building in the corporate environment always works on a clean image. That's the way I've done it for years when I was a ZENworks consultant. No customer in their right mind would build packages on dirty images. You would spend 5 times as much time building trying to troubleshoot what on your image made things go wrong.
Definition of clean == freshly installed system with all devel packages. There. Problem solved. not saying to NOT clean out build roots between builds, just that they standard build system have the default CLEAN(freshly installed) packages installed. Unless you are saying that a fresh, clean install of SuSE is dirty? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Linda Walsh wrote:
Definition of clean == freshly installed system with all devel packages.
---- Forgot something -- While with a normal corporate environment, what you say is often true, you must remember, you are a *distribution* company that specializes in putting all these packages together and making them work. Considering it like eating your own cooking... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Monday 16 of July 2012 20:35EN, Linda Walsh wrote:
On Mon, 2012-07-16 at 20:23 -0700, Linda Walsh wrote:
Stop building on empty systems -- they don't represent what any customer has in the field.
Definition of clean == freshly installed system with all devel packages.
There. Problem solved.
No, this does not solve any problem. This is only the point where the problems would start. I've seen strange build problems caused by package being built with environment set to German locale. For a lot of projects, result of configure script - and thus the resulting package - depends heavily on what libraries are installed in your system. I even know of at least one project whose build fails if the package is already installed and the daemon is currently running (maybe even if it has been run at least once). Experienced package maintainers could certainly add a lot more examples. No. The only sane way to get (at least to some extent) reproducible build results is to build in well defined and minimum build environment, not in the installation intended for daily use. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Jul 17, 12 12:03:58 +0200, Michal Kubeček wrote:
On Monday 16 of July 2012 20:35EN, Linda Walsh wrote:
Definition of clean == freshly installed system with all devel packages. No. The only sane way to get (at least to some extent) reproducible build results is to build in well defined and minimum build environment, not in the installation intended for daily use.
Can we define in the specfile that a package must not be present? E.g. prohibit that the package itself is already there: BuildRequires: -%{name} cheers, JW- -- o \ Juergen Weigert paint it green! __/ _=======.=======_ <V> | jw@suse.de back to ascii! __/ _---|____________\/ \ | 0911 74053-508 say #263A!__/ (____/ /\ (/) | _____________________________/ _/ \_ vim:set sw=2 wm=8 SUSE LINUX Products GmbH, GF: Jeff Hawn, J.Guild, F.Imendoerffer, HRB 16746 (AG Nuernberg), Maxfeldstrasse 5, 90409 Nuernberg, Germany SuSE. Supporting Linux since 1992. ☺ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Le mardi 17 juillet 2012 à 12:30 +0200, Juergen Weigert a écrit :
On Jul 17, 12 12:03:58 +0200, Michal Kubeček wrote:
On Monday 16 of July 2012 20:35EN, Linda Walsh wrote:
Definition of clean == freshly installed system with all devel packages. No. The only sane way to get (at least to some extent) reproducible build results is to build in well defined and minimum build environment, not in the installation intended for daily use.
Can we define in the specfile that a package must not be present? E.g. prohibit that the package itself is already there:
BuildRequires: -%{name}
BuildConflicts: is for that (but it is usually not used, because empty
chroot are the only reproducible sane way to produce packages and it is
not a SUSE only idea..)
--
Frederic Crozat
Hello, On Jul 17 12:30 Juergen Weigert wrote (excerpt):
Can we define in the specfile that a package must not be present?
Use #!BuildIgnore: unwanted_package Example: $ osc cat graphics sane-backends sane-backends.spec | grep -B 6 BuildIgnore ---------------------------------------------------------------------------- # texlive-latex is needed to make doc/sane.ps from doc/sane.tex # but texlive-latex requires texlive which requires ghostscript-x11 # but ghostscript-x11 is not needed for sane.tex -> sane.dvi -> sane.ps # so that the needless package ghostscript-x11 blows up the build system # and is explicitly excluded to be installed in the build system: BuildRequires: texlive-latex #!BuildIgnore: ghostscript-x11 ---------------------------------------------------------------------------- Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
It is not my intention to throw petrol on this fire but it seems to me that the disagreement between the two camps in this discussion is that: 1) Linda wishes to build against a fully installed system (a "standard" openSuSE) 2) Opponents insist that you build against a completely empty chroot environment Surely they are entirely different environments because the protagonist has a different objective for their build environment (you are BOTH right): 1) is rebuilding a finalised system from scratch against a finalised system 2) is building packages for testing to iron out bugs with the package being developed Gentoo design their packages ('emerge' packages) to be built against a fully installed system and there can be conflicts during that building which sometimes require the backing out of packages or "masking" of packages that don't yet work against the "finalised system". They achieve 1) by avoiding the build of known conflicting packages in a production environment - "Dangerous" packages are offered for building but they are "masked" - because they may/do cause conflicts/build problems. Consequently, I have not encountered a problem building the default system (the "standard" gentoo) from scratch because there was some UNKNOWN conflict that required a completely clean build environment. It would seem reasonable to want to build a "standard" openSuSE system from scratch using the production environment i.e with potential conflicts having been ironed out of the packages being built - if source code is taken from a PRODUCTION source repository i.e. not a FACTORY/DEVELOPMENT source repository for building in a FACTORY/DEVELOPMENT environment. One != Other. To achieve both requires the hosting of two different source environments: 1) Final source for building of production environment against "standard" openSuSE install 2) Factory/Development source for building in a clean environment while ironing out bugs in packages/setups/configurations ready for inclusion in (1) BOTH 1 and 2 are desirable for different purposes. Site maintainer needing to rebuild "standard" openSuSE = Happy AND Developer needing to clean test development package = Happy DEPENDS Both understand that 1 != 2 Mike P.S. I am not offering to maintain/host either source repository NOR do the work moving packages from 2 to 1. P.P.S. OpenBSD and FreeBSD achieve 1) and 2) through their 'stable' and 'current' branches respectively. On 17/07/12 11:03, Michal Kubeček wrote:
Stop building on empty systems -- they don't represent what any customer has in the field. Definition of clean == freshly installed system with all devel
On Mon, 2012-07-16 at 20:23 -0700, Linda Walsh wrote: packages.
There. Problem solved. No, this does not solve any problem. This is only the point where the
On Monday 16 of July 2012 20:35EN, Linda Walsh wrote: problems would start.
I've seen strange build problems caused by package being built with environment set to German locale. For a lot of projects, result of configure script - and thus the resulting package - depends heavily on what libraries are installed in your system. I even know of at least one project whose build fails if the package is already installed and the daemon is currently running (maybe even if it has been run at least once). Experienced package maintainers could certainly add a lot more examples.
No. The only sane way to get (at least to some extent) reproducible build results is to build in well defined and minimum build environment, not in the installation intended for daily use.
Michal Kubeček
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (8)
-
Bryen M Yunashko -
Frederic Crozat -
Johannes Meixner -
Juergen Weigert -
Linda Walsh -
llemikebyw＠aol.com -
Michal Kubeček -
Richard Brown