Jeff Spaleta wrote:
On 9/12/07, Les Mikesell lesmikesell@gmail.com 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.