Proposed F13 feature: drop separate updates repository

[Daniel P. Berrange]

On Wed, Dec 02, 2009 at 05:47:17PM +0000, Matthew Booth wrote:
> 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.

That sounds like something for a yum plugin to solve. eg

Have a URL you can query to get a list of valid repos for a particular
release. Have a YUM plugin implements a virtual repo, and this repo
simply fetches that URL, and then exposes a package set which is the 
union of all repos listed. That way we still have separate YUM repos &
separate metadata hosted on all the servers, but the clients can all
be configured with this single virtual repo


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|