On Thu, Dec 29, 2005 at 02:49:21PM -0500, Jeff Spaleta wrote: > On 12/29/05, Axel Thimm <Axel.Thimm@xxxxxxxxxx> 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
Attachment:
pgpyjDKToFNds.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
