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

Re: Proposed F13 feature: drop separate updates repository

On 02/12/09 16:06, Josh Boyer wrote:
On Wed, Dec 02, 2009 at 03:44:08PM +0000, Matthew Booth wrote:
On 02/12/09 15:26, Josh Boyer 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.

So lets fix it.

And how do you propose to do that?

Unfortunately I'm not intimately familiar with Fedora infrastructure
under-the-hood. However, I would hope that, technically at least, it
wouldn't be much more than a systematic removal of all updates
repositories and redirecting files which would have gone into them into
the main repositories instead. This stems from the observation that if
you copied everything from the main repository into updates you would
have created the repository which people unfamiliar with the history
would expect. The infrastructure side of this, on the face of it, sounds
very simple.

What you describe is effectively how the development repository is built,
so it's certainly a technical possibility.  It does have implications
though.  Off the top of my head, I can think of:

1) Composing a new everything tree for updates would lead to larger
compose times.  That could possibly mean that getting updates out would
take>  1 day per 'push'.  We've been trying to improve updates push
times so it would be a bit detrimental to that goal.

I can't comment on this.

2) There might be GPL compliance issues

This line of reasoning sounds bizarre to me. You can publish things in multiple places.

3) You would still need an 'updates-testing' repository given that this
is a supposedly stable release.  So there is still going to be at least
one additional repo regardless.

Indeed, however that would only be testers. Most people can ignore it.

However, other than 'browsing manually for packages', I'm not really
sure what problem you are trying to solve by getting rid of the
updates repository.  It would seem like this has quite a bit of cost
for relatively little to no real gain?

Any tool which deals with repositories requires the repo to be configured twice. Off the top of my head I can think of:

1. yum
    separate repo and updates-repo in yum.conf.
2. livecd tools
    two repos in kickstart
3. revisor
    two repos in kickstart
4. febootstrap
    two repos on command line

Given that you almost always want updates, it would an improvement if all of the above could be replaced with a single configuration.

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

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