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 :| -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
