On 11/29/2005 02:58:55 AM, Axel Thimm wrote:
On Mon, Nov 28, 2005 at 10:57:48AM +0100, Benny Amorsen wrote: > >>>>> "WR" == Willem Riede <wrrhdev@xxxxxxxxx> writes: > > WR> Maybe I shouldn't care, but I do. As an example, with all due > WR> respect to its creator, the atrpms repository holds both packages > WR> I want (unique functionality) and that I don't want (core > WR> replacements). Unfortunately that means I can never do a blind > WR> cross-the-board upgrade from all the sources I've identified. > > It would be very nice if one of the update utilities could be set to > ignore updates across repositories. I.e. if I've installed foo from > core and bar from atrpms and atrpms has newer versions of both foo and > bar, only bar gets updated. Maybe it's better to avoid atrpms at all then, as its bar will probably assume that you are using foo from the same source? Perhaps foo in core is being replaced just to add the functionality that bar needs?
Good point. I would hope that in such cases the bar from add-on repos has an explicit Requires: on the foo fromthe same repo...
It isn't as black or white as it seems. I've had enough bug reports on using apt and smart with priorities/weights to strongly advise against their use (not apt/smart's, but their weighing mechanisms). And if you don't trust repo X to replace package Y, then why trust it to offer package Z? Better drop repo X, if you feel uncomfortable.
Well, that aspect is also not black and white :-) Some repo may have several clusters of changed or additional rpms, and I may want one of those clusters because my desire for that functionality is larger than my concern for the system's stability, but I am happy with the base distribution for other clusters, so I don't want those replaced.
The way I'd love to be able to do it, is to initially explicitely install new rpms and accept upgrades due to dependencies of the rpm that provides the new functionality, and later when doing "yum update" have only rpms that originate from the same repo as what is already installed (on a package by package basis) selected.
Thanks, Willem Riede. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
