On Wed, 4 Aug 2004 09:39:47 -0400, Jeff Spaleta wrote: > On Wed, 04 Aug 2004 12:23:29 +0200, Ralf Corsepius <rc040203@xxxxxxxxxx> 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.
