Dne 30.1.2015 v 20:13 L.A. Walsh napsal(a):
Ruediger Meier wrote:
Is there really no other way to solve these build loops?
There is a well established way to solve them.
Bootstrapping.
You build an intermediate build from an official repo of the last generation -- if it can be build with the last official "published altogether" repo (w/o any patches), that would be the best.
That builds your new generation of build tools for some "period" of time, only introducing non-interdependent products at any new build -- then test the *** out of those. It wouldn't have to be a complete test of the whole distro, but some "core" set that is needed to rebuild the distro each time.
Those cores become official build tools that are archived with *their* build tools and their sources from the previous generation.
Bootstrapping all-in-one with previous generation goes against the spirit of the openSUSE Build Service. When any single bit is changed in the package, OBS triggers to rebuild all packages that have that just-rebuilt package as build dependency. Even distributions using the bootstrap image may require three rebuilds or so to get core into a consistent state. OBS prevents superfluous rebuilds. If the package is not changed after the rebuild, no rebuild triggers are activated. But in case of util-linux, build trigger apparently were activated several times. util-linux is a bit heterogeneous set of utilities. Some of them are part of main core, others have high level of dependencies. Such core would contain e. g. python-libmount, which is invalidated by python version upgrade. But python rebuild requires tk (i. e. Xorg), just because python is another large heterogenous package. So now you have to decide: - Include Xorg and tk to the core. - Split util-linux or python build to multiple stages. - Use several thousands more rebuilds to get core into a surely consistent state. - Don't do anything of above and live with a risk of breakage.
Should it really take more than 1 BR disk / core + 2 backups for safety?
I mean this is what you would do if you didn't want to operate building skyscrapers on shifting sands all the time.
Could be a reason to justify supporting compatible and or co-existing core tools for longer periods of time rather than dropping something one cycle, only to sub in something else next. But it would take some planning a dedication to keeping a plan -- and not allowing many (if any) exceptions.
If you upgrade python, python-libmount (part of util-linux) becomes invalid. If you upgrade systemd, then uuidd, lslogins and logger may need to be recompiled. If you upgrade util-linux, it is safer to say that the whole core becomes outdated.
At least this was the way product release was handled back before the era of the 'continuous/rolling Beta'....
This was done always in SUSE. Now it is just more visible.
Seems like some sort of spreadsheet tool could be ideal for this type of job...
In case of util-linux, there are large dependency cycles with about 2000 packages on the round. The OBS paradigm "better safe than fast" brings some problems, some discovers as early as possible and prevents another. I remember problem of constant libraries breakage in early days of Gentoo caused by a complete lack of rebuild triggering.
Aren't you basically lamenting the fact that the tools are released in constant 'partially done' states that are not always consistent at anyone time?
OBS has a status "Done".
If that works -- great, but it's alot more effort, but managing a 'core-set' like a git/cvs-checkin that is tagged to represent 1 product is a bit of a chore, but I'd expect that most products, at least still do that on a product-by-product basis...no?
-- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org