[Yum-devel] RFC: Best providers repo. metadata (initial implementation)

[Tim Lauridsen]

James Antill wrote:
>  There are a growing number of cases where we have a virtual provide X,
> that is satisfied by N packages but the repository owner knows that only
> N-M should be considered.
>  For instance:
>
> 1. smtpd, smtpdaemon, /usr/sbin/sendmail, MTA, server(smtp)
>
>    These are provided by a lot of things, where Fedora/etc. will almost
> certainly only want postfix installed instead of exim (shortest name).
>
> 2. java-devel
>
>    Here we actually have had bug reports in Fedora (not the only ones),
> as openjdk and gcj provide the same thing, and again shortest name wins
> but Fedora wants openjdk to win.
>
>  So here's my initial implementation:
>
> 1. Create a simple XML format for "best providers", idea being that it
> won't be that big and only needs provides and package names. Sample file
> is:
>
> <?xml version="1.0" ?>
> <bestproviders>
>   <bestprovider>
>     <provide>/usr/sbin/sendmail</provide> <provide>MTA</provide>
>     <pkgname>postfix</pkgname>
>   </bestprovider>
> </bestproviders>
>
> 2. Yum looks for a 'best_providers' metadata type from repomd.xml and
> creates a per. repo. 'best providers' followed by a global one.
>
> 3. If we hit compare_providers() then we filter to data in the best
> providers and give them a big score increase.
>
> 4. I also changed "yum install smtpd" to go through compare_providers()
> instead of it's own simplified version it had.
>
>
>  Patch is at:
>
> http://james.fedorapeople.org/yum/patches/yum-best-providers-metadata.patch
>
>  Sample repo. with best_providers data (i386 and x86_64 only):
>
> [and.org-OS-updates]
> name=And.org OS updates
> baseurl=http://www.and.org/yum/fc$releasever-$basearch-updates
> enabled=true
>
>
>  Comments? ... things to think about:
>
> 1. It's only provide => package name ... is that enough? Possibility of
> more data: allow full nevra type preferences, allow conditions based on
> what/if package requires the provide and allow specific scores so pkgA
> is preferred over pkgB, etc.
>
> 2. Atm. we say "if the requiring package comes from repoA, then do a
> best provider lookup in repoA ... if that fails do a global lookup. If
> we don't have a requiring package we just do a global. For the global
> data we just merge everything from all repos.
>  Is this too much? My intent was to allow two repos. to provide say
> my-video, and one to prefer gstreamer but one prefer xine, but I'm not
> 100% sure it's worth it ... it's certainly easier to just have a global.
>  Is this not enough? As above, but I could see cases where you'd want to
> say "use Fedora, but with this local repo. and have BLAH as the
> preference for FOO".
>
>   
I think it is a good idea to have some way to define best provides, but 
i think we have a lot a different metadata files
maybe be we should think about consolidate some of the information somehow.

* repomd
* primary
* filelists
* other
* update matadata
* comps
* best providers
* other future stuff like. package tags.



Tim