On Wed, 2007-09-05 at 08:27 +0200, Tim Lauridsen wrote:
> > simple-local-repo-priority - allows you to setup a local repo that has
> > SOME of the pkgs from another repo and know that the ones in the local
> > (or better priority repo) will be used. This only works for nevra-exact
> > pkgs from one to the other. This is useful for anaconda, mock, mash, etc
> > to let it know to use a closer copy of some of the files rather than a
> > remote one.
> >   
> This is more like a repo cost to me, if more packages exist with the 
> same nevra the take the cheapest one.
> Very nice and useful, but it have a different purpose that the other ones.

You and jantill have said more or less the same thing. I think you both
have a point. I've been referring to this incorrectly. Maybe 'cost'
could be implemented as a plugin and/or in core which would handle the
case of 2 locations offering the exact same pkg but the more expensive
one is excluded.


> What about this one.
> repo-group packages is only updated by packages from the same repo group.
> [base]
> ...
> ...
> group=base
> 
> [updates]
> ...
> ...
> group=base
> 
> [foo]
> ...
> group=foo
> 
> [bar]
> ...
> group=bar
> 
> packages installed from base & updates is only updated by packages from 
> base & update.
> packakges installed from foo is only updated from foo.
> packages installed from bar is only updated from bar.
> 
> I know we can't do that before we have some way of storing the source of 
> the installed packages.
> This would solve most repo mixing screw ups.

It would solve them - it would also create a number of headaches. An
example:

user has: 
fedora
3rdpartyrepo
fedora-upates

the user installs something from 3rdpartyrepo which they don't have
installed yet on their system from fedora. The version in 3rdpartyrepo
is newer/better/something. Then 2 months later the version from
3rdpartyrepo is now incorporated into fedora-updates. Then the user is
more or less screwed for getting that legitimate update.

-sv


_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel

Reply via email to