Jeff Spaleta wrote:
On 9/12/07, Les Mikesell <lesmikesell@xxxxxxxxx> wrote:
Or, if you need another level of indirection, include a repo that
doesn't itself have anything controversial but has a package that
configures yum for repos that might.
oh classy. So how would that work from a user perspective?
Let's say the repo you describe exists... let's call it the
repo-clearinghouse repo. It essentially holds release packages for
each addon repo that can be installed thus configuring the client to
pull packages from different addon repos.
Obviously yum install repoA-release will install the release
package for repoA, as held in the clearinghouse repo... but how do you
expose things in a way that a user can ask which addon repo they need
to configure?
How does a user know about any other package and decide if they would
like yum to install it? A name convention for packages so something
like 'yum search repo' would find a list of repos that yum could add to
itself.
Say I want support for the new foo codec that can't be shipped in
Fedora. Do i look in repoA or repoB or repoC ? How would the
repo-clearinghouse repo expose that repoA was the correct location to
find all things related to foo codec? How do I ask which repo to
configure through interaction with the repo-clearinghouse metadata
specifically to get access to all foo codec related packages?
'yum info repoA-release' might describe why you would want to install
access to that repo, perhaps to the extent of having the package list or
at least the ones that you felt could be legally mentioned everywhere.
But, I thought the point of rpm-fusion was to become the only extra repo
you might need so this decision wouldn't be too complicated.
--
Les Mikesell
lesmikesell@xxxxxxxxx
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
