[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Please rebuild your packages in the development tree of Fedora Extras



On Tue, 2006-02-14 at 12:43 +0100, Michael Schwendt wrote:
> 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.
Let me pull you this tooth - In the vast majority of all cases, you
don't need a particular OS/version of an OS to test whether a package is
functional, because most packages' functionality is independent of any
OS. Therefore testing update/upgrade-packages on such similar OSes (e.g
FC4 vs. FC5) will be enough in many cases.

Also you can't expect to a package that is known to work on one
architecture to work on others, and require all maintainers to test them
on all architectures - That would be irrational nonsense.

>  There are
> packages in the repository which are not orphaned, which have been
> rebuilt, but which don't work or which hardly work well.
File bugs to bugzilla, that's what bugzilla is for and what
rawhide/development is for: Testing SW and identifying bugs!

>  The information
> we are seeking is: What changes in Core/GCC/ABI/BuildRequirements/DepChains
> _require_ a rebuild of a package in Extras?
Such cases require a rebuild. They should be detected automatically and
should be triggered automatically. If this isn't possible, this has to
be done manually by a centralized instance, either an individual or
"rebuild task force".

>  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.
This would not justify a mass rebuild because this doesn't qualify a
package as non-functional. A gradual rebuild would be sufficient.

>  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.
This would qualify as a packaging bug, should be bugzilla'ed and be
addressed by normal bugfixing

>  So, to decide when something needs
> a rebuild, I need to monitor dependencies.
Right, more aggressively: changing deps should trigger rebuilds.

>  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.
Not necessarily. If a packages ABI/API don't change upon
upgrades/updates, there should not be any need to rebuild a package.

>  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.
But that's what FESCO currently is doing: You are producing 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_
Exactly. As long as a package can be correctly installed and seems to
work, there is no need for immediate action.

If it can't be rebuild, ... bugzilla ...

> > 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,
Nevertheless it had been much better than what is being tried now.

>  btw, since some packagers
> performed major version upgrades shortly after the rebuilds had been done.
Packagers perform major upgrades when they "happen". 

In some cases it's a random point in time, in some cases it's the mass
rebuild co-incing with "last minute" updates. It has happened and it
will happen again, you can't prevent it, and I don't see any reason why
one would want to prevent it.

> > > 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.
Partial mirroring sees the older version - This renders using local
mirrors of devel over a low bandwidth connection tedious.

Ralf




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]