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. 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. At least this was the way product release was handled back before the era of the 'continuous/rolling Beta'.... Seems like some sort of spreadsheet tool could be ideal for this type of job... 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? 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? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org