Axel Thimm <Axel.Thimm(a)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