On 02/12/09 16:01, 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.
That's not a bug, it's a feature! Seriously, wasn't it a specific F10 or
F11 feature that anaconda allowed the user to specify that updates be
installed at installation time? Certainly I used to have Debianites crow
at me that my installation was vulnerable until I updated it. Not only
that, but I had to download updated packages twice. These days I always
install with updates. I find the installation argument dubious at best.
Still, we could rename the main repo the 'installation' repo, and
nothing but anaconda would ever look at it. Everything else would look
at the main repo, which would be the same as the current updates repo
except with everything in it from the start.
Matt
--
Matthew Booth, RHCA, RHCSS
Red Hat Engineering, Virtualisation Team
M: +44 (0)7977 267231
GPG ID: D33C3490
GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
