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@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... 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
Attachment:
pgpCaGXGx950u.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
