FC5 and Yum Plugins

Horst von Brand vonbrand at inf.utfsm.cl
Mon Jan 2 16:19:57 UTC 2006

Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> On Thu, Dec 29, 2005 at 03:28:34PM -0500, Jeff Spaleta wrote:
> > I think protectbase by default is a particularly bad idea for a
> > number of reasons. But if i understand the original poster
> > correctly, the problem he wants solved is a way to easily update
> > packages in a way that recognizes from where installed packages were
> > originally installed from after selectively install packages from a
> > number of different vendors.  I don't see a good solution to this
> > problem since the rpmdb doesn't keep track of this sort of
> > information. The closest thing that can be used to aid this sort of
> > update is gpg signatures.

> I agree, this is a different problem at all. But even then I would
> reconsider. Assume package foo exiting at ATrpms at FC<N> time, and
> then it makes it into FC<N+1> core. You wouldn't want to exclude the
> upgrade path to another repo. Also some packages may be dropped by FC
> like pine was, and it may reappear in another repo. Again, you'd like
> to have upgrade paths not accidentially broken due to vendor/origin
> lock mechanisms.
> I think these idioms are trying to cure something at the wrong
> end. I'd ask the following:
> o What needs to be fixed?

PEBCAK: Don't just "upgrade all" from external repositories, "upgrade
the-package" only. If there are dependencies that must be satisfied from
the external repo, it pulls them in; if not, nothing is changed. If
standard packages are overwritten, well...

Perhaps an easy way of telling yum to pull from a (disabled, or marked
external in some other way and thus not considered by default) repository
would solve most of the problem?
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

More information about the fedora-devel-list mailing list