status of up2date and rhn-applet

[Axel Thimm]

On Tue, Nov 29, 2005 at 10:22:53PM +0000, Willem Riede wrote:
> 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...

how would you do that? rpm only allows specifying a name and a
version. Requires: foo-from-repoX is an ugly hack nobody wants to see.

> >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 issue is indeed that you'd like to see some of the clusters in
separate sub-repos. But everyone has a different preference of what
these subrepos should be. If a repo maintainer would be to implement
this splitting he would be doing nothing else. Consider also sub-repos
sharing packages, like fftw for scientific and multimedia repos.

It is a living nighmare. I have though about that a lot to get off the
discussion on weighted and prefered subsets of packages, but the
Gedankenexperiments always ends with catastrophies.

> 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.

Same problem, if you want foo from repoX, and bar remains on repoY's
functionality .
-- 
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://listman.redhat.com/archives/fedora-devel-list/attachments/20051201/432293a8/attachment.sig>