Fedora Extras vs. CLOSED RAWHIDE

Michael Schwendt fedora at wir-sind-cool.org
Wed Aug 4 22:52:13 UTC 2004


On Wed, 4 Aug 2004 09:39:47 -0400, Jeff Spaleta wrote:

> On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius <rc040203 at freenet.xx> wrote:
> > As I already tried to outline, I can image several technical approaches:
> > 
> > 1) In exceptional/special cases, Fedora.us/FE should be permitted to
> > replace packages from FC if they break other FE packages or are unusable
> > in general.
> 
> I'm confused... if a package is already in FE how can a lack of an FC
> update break it?

You gave the answer further below. --> It can't. It can only make a new FE
package release impossible. Either because the FE package can't be built
due to insufficient dependencies, or because the FC package contains
problems which [seem to] affect only the FE package. perl-DateManip as an
old example which was fixed with an unofficial update which would not be
possible with a strict policy about what FE is permitted to contain.

There's one exception, however. A FE package included in (or moved into)
FC. If the package release in FC is not upgraded for bug fixes, the FE
packages for older release of the distribution cannot be upgraded
either. Because that would break the upgrade path. One example is k3b,
where fedora.us waited for FC2. ALSA in FC1 is an example, where all of a
sudden, FC2 development didn't move beyond 1.0.3a despite all the problems
with ALSA. To release driver updates and upstream fixes for several bugs
and problems, fedora.us upgraded FC1 ALSA to 1.0.4. Otherwise the ALSA
roll-out for FC1 would have stopped unexpectedly. No further early testing
of ALSA drivers and apps in FC1 would have been possible.

-- 
And, of course, kernel updates break extra repositories temporarily, too,
as users of add-on kernel modules cannot update their kernel before
updated module packages are available.





More information about the fedora-devel-list mailing list