Proposed F13 feature: drop separate updates repository

Daniel P. Berrange berrange at
Wed Dec 2 16:19:16 UTC 2009

On Wed, Dec 02, 2009 at 10:01:51AM -0600, Justin M. Forbes wrote:
> On Wed, Dec 02, 2009 at 02:39:30PM +0000, Matthew Booth wrote:
> > The separate updates directory has been a pain for as long as I've been 
> > using RHL/Fedora Core/Fedora. It means you have two places to look when 
> > searching for packages manually, and twice as much to configure when you're 
> > configuring yum. It has never benefitted me, or anybody I know, but it has 
> > caught me out on any number of occasions. What's more, nobody really seems 
> > to know why it's like that: it seems it's always been that way, and nobody 
> > ever bother to fix it.
> >
> The only downside to merging updates into the main repository is that
> network installs from the repository will no longer install the "release"
> they will install the updated release.  QA that goes into that first
> impression is no longer there, and your installs are not repeatable because
> installing system A on one day and system B on another could end up with
> different versions of packages.  Of course you can always install from the
> ISOs to avoid these problems. As things are, you have the choice of the
> "release" as it was, or the updated release at install time.  I am not
> saying that this is a bad idea, in fact I rather like it, but there are
> things to consider.

I think this is quite a compelling reason not to touch it. Much as we'd
like the updates repository to always be perfectly stable, there are 
still plenty of occassions when we hit problems with updates. Being able
to reliably install the release at all times is pretty critical & saying
we should install off ISO if we want a reliable install is not really an
acceptable alternative since many people do all their installs straight
off the network.

|: Red Hat, Engineering, London   -o- :|
|:  -o-  -o- :|
|:       -o- :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

More information about the fedora-devel-list mailing list