FC5 and Yum Plugins

[Axel Thimm]

On Thu, Dec 29, 2005 at 02:49:21PM -0500, Jeff Spaleta wrote:
> On 12/29/05, Axel Thimm <Axel.Thimm at atrpms.net> wrote:
> > Exactly. Which is why any repo, be it atrpms or something else, that
> > does see a need to replace package foo in core, and thus has
> > overlapping package sets with core will not like this idiom. I have
> > already been hit by bug reports that stem from improper use of
> > priorities/weights and scores. Such filtering creates a lot more
> > issues and debugging problems than it solves.
> 
> let's be clear.... if protectbase plugin was turned on by default
> would atrpm leave it enabled on client system or would you attempt to
> disable the plugin via package scriptlet action?

That sounds too sneaky. While such a setup would generate grand
headaches to most 3rd party repos (if not all, if there any big one
w/o replacements?) as you and Thorsten already outlined (so it's
better not to get as far as to have this as a default), I'd rather
find a different solution to this problem, and I believe the other 3rd
party repo maintainers would feel the same. It's not a repository war
to invent new ways of dumping the other side (I hope).

Certainly this kind of yum setup would not be a supported setup by the
repos needing these replacements, so either way you look at it, this
idiom cannot be welcomed by any such repo. In fact it would make yum
itself as a depsolver unusable for these repos.

So to answer your question directly: ATrpms would try to avoid such a
setup by all (fair) means, and not having ATrpms at all on your client
system would be a preferable setup to one with broken dependencies.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20051229/97e38d4e/attachment-0002.bin