Please rebuild your packages in the development tree of Fedora Extras

[Michael Schwendt]

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.