On Donnerstag, 26. Februar 2015, 15:05:27 wrote plinnell:
Hi,
Some comments inline, but I will say the automatic rebuilds triggered in OBS are definitely a feature and not a defect :)
sure ;)
On Thu, 26 Feb 2015 16:26:38 +0800 Ji Xiang
wrote: On Thursday, February 26, 2015 08:26:09 AM Adrian Schröter wrote:
On Donnerstag, 26. Februar 2015, 14:59:21 wrote Ji Xiang:
Hello everyone, I have been confused for long time in terms of the rebuild (or I can say 'scheduling') mechanism of OBS. The most confused point is why a full rebuild is needed for software release on OBS.
Well if it is "needed" can always be discussed. But it is needed _IF_ you want to be sure that you are able to rebuild it after releasing it (eg. the newer gcc may just crash or header files suddenly provide conflicting definitions). Also some changes could apply which are not expressed in the dependencies of packages.
Many thanks for your kind of answer, do you mind give me a example what kind of the change which are not included in the dependency? The major reason I asked this question is we are using OBS, however we found that it takes quite long time to do a full build(some packages are built many times due to the dependency), and if there are some changes happened at low layer(like glibc , qt etc), all the packages will be built, we have to wait for long time. It can not met the requirement of fast release process.
If glibc or Qt are rebuilt for some reason, you *defintely* want packages which depend on them rebuilt. This the magic of OBS which guarantees all packages publish in a coherent state. If you do not you may have symbol mismatches or location errors among other nastiness.
It depends heavily on your expectations here. You can argue of course that glibc and Qt must not become backward incompatible. Even worse you may hide this incompability which is not acceptable for a stable product. Therefore we do NOT rebuild everything for stable products (aka maintenance updates). But we definitive want a rebuild for all upstream work. If there is a breakage we want to know as early as possible. Not month later and for sure not after the product got released. Listen to talks from other distros who have the problem that a significant number of packages which were part of a release do not actually build anymore. And that is really the worst case scenaria when you need to do way more changes in a released product then needed for a simple fix. It increases the risk of side effects a lot and requires way more QA testing then. -- Adrian Schroeter email: adrian@suse.de SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org