status of up2date and rhn-applet

Willem Riede wrrhdev at riede.org
Tue Nov 29 22:22:53 UTC 2005


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 at riede.org> 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.




More information about the fedora-devel-list mailing list