Proposed F13 feature: drop separate updates repository

[Matthew Booth]

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.

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