On Tue, 14 Feb 2006 07:20:18 +0100, Thorsten Leemhuis wrote: > > 1) A forced rebuild, just to check whether a package still builds, is > > something that can be done by the maintainer _locally_ using mock or with > > FC5 Test 3. > > You forget that we have some packagers that live in parts of the world > where internet bandwidth is costly. I suspect that each rebuild for > devel with mock will download 300 - 750 MByte. To much for those > packagers afaics. That's just another exception. As is a package which doesn't need a rebuild. A packager who's not running Rawhide--or at least one late test release--cannot test the binaries at all prior to FC5 being published. That would be an unfortunate situation. That even bears the risk of publishing binaries which don't work but which upgrade older still-working binaries, and--in case upstream development help is needed--which will remain broken until a fix is ready. We want package maintainers, who keep their stuff working. We don't want packaging slaves who rebuild because they are told to rebuild. There are packages in the repository which are not orphaned, which have been rebuilt, but which don't work or which hardly work well. The information we are seeking is: What changes in Core/GCC/ABI/BuildRequirements/DepChains _require_ a rebuild of a package in Extras? For instance, if I'm told that the updated compiler gives significant performance improvements or adds more security features or reduces the risks of miscompilation this would be reason to rebuild my binaries although everything seems to work fine in current Rawhide. Or if I see that some of the build requirements I depend on have changed, I'm interested in how this might affect my own packages at build-time and at run-time. So, to decide when something needs a rebuild, I need to monitor dependencies. Similarly, before I perform an upgrade to one of my packages, I need to watch and test carefully whether anybody else might be affected by the upgrade in bad ways. That's the whole big show that's supposed to just work within Fedora Extras all the time. API/ABI breakage, e.g. It is mandatory that I perform local test-builds of packages which depend on my packages. Where not possible due to lack of bandwidth, more coordination is necessary among the package maintainers. I cannot simply commit my upgrade and then be confronted with the wreckage. > And even if that wasn't a problem -- how do we make sure that people > really tried if a package still builds? Do we care? I'm mainly interested in whether a binary package _works_ in the form we offer it in the repository. It doesn't interest me much, whether the src.rpm might be out-of-date and may need adjustments for broken BR dep chains (like modular X's). Either the maintainer will notice prior to next upgrade or a user will report it. If neither happens, do we care? There are packages in the repository which nobody other than the packager seems to use. As much as I'm opposed to "rebuild for every dist just to keep spec files in sync" I'm opposed to unnecessary rebuilds in general. So, again and again: Either a package hasn't been built for some time and would benefit from a rebuild with the new GCC. Or there are reasons why it doesn't need a rebuild, and in that case the time it was built doesn't matter at all. > > 2) There are exceptions. Noarch packages which really don't need a rebuild. > > Either it does or it doesn't. If it doesn't, the rebuild/update is not > > needed. > > Maybe -- but where is the problem with rebuild? Yeah, packagers have to > invest a bit of time to increase the Release, add a changelog entry and > request build. But other that that is mostly machine time that is spend. Again, why rebuild stuff that doesn't need a rebuild? > And we have a lot of not that important packages in the tree now, some > of them are rarely updated upstream (take tiobench for example). We > might never notice if that package is orphaned if we always do a > script-mass-rebuild... Yes, a scripted mass-rebuild introduces a false sense of activity. Who skims over the build logs to watch out for failed configure tests which leave out components? Who makes sure the binaries still work? My experience with the last mass-rebuild is bad, btw, since some packagers performed major version upgrades shortly after the rebuilds had been done. > > We may remove what's broken and track it on the FC5Status page in the > > Wiki just as we did for FE4 and older. > > Well, let's see how this whole thing works out. But what I'd really like > to remove before we publish FE5 are old packages from the tree when a > successor is there. E.g. when both foo-1.2.FC4 and foo-1.3.FC5 are in > the FE5 tree remove foo-1.2.FC4. That okay for everybody? A normal yum update/upgrade only sees the latest one anyway. -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
