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(a)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