Alexandre Oliva wrote:
On Jan 24, 2005, Axel Thimm <Axel.Thimm@xxxxxxxxxx> wrote:
On Mon, Jan 24, 2005 at 03:05:29PM -0200, Alexandre Oliva wrote:
On Jan 24, 2005, Ralf Ertzinger <fedora-devel@xxxxxxxxxxxxxx> wrote:
The problem with this is that RPM does not indicate whether a package hasCould we perhaps add such a flag to the rpm database? Then the
"end user value" (a command line or GUI program, or a daemon), or is just
a support library needed by said end user programs, which can be removed
if not needed by anyone.
installer and the various other package installation front-ends could
mark user- (or comps-)requested packages as having end user value, and
everything else brought in to satisfy dependencies such that it is (or
can be) removed as soon as no dependencies remain.
ATrpms has started marking library only packages with
Provides: shared-library-package
so these packages can be identifies with
rpm --whatprovides shared-library-package
and be probed for garbage collection.
The weak point of your argument is that it assumes that the only kind of package that doesn't provide "end user value" is the kind that provides shared-library-package. This is just not true, although I must admit it's the most common case.
Having package installers pin user-selected packages, or unpin
packages brought in only to satisfy dependencies, would enable all
cases to work, not only the shared library case, even without a
special provides or the too-inclusive mechanism proposed by jeff.
The concept of "pinning" can will stop a depsolver from unattended, batch mode,
upgrades.
But up2date certainly has (at least) the two essential "pinning" concepts: a) Never change this package. b) Never change this file. and yum has (at least) a).
I.e. there is no need to extend rpm, you have everything already in
place.
Not quite. Consider that I might actually want to keep a shared lib
around (say libdvdcss, only used as a plugin by libdvdread). With
your scheme, there's no way to tell it from any other shared
lib-providing package, so it could be garbage collected along with
other libs. Sure enough, I could install my own meta-package with an
explicit requires to keep the lib-providing package installed, but why
should I have to go through these hoops if rpm might instead offer a
`user-requested' bit to keep a package installed even if nothing else
requires it?
The real problem with "pinning" is one of mechanism vs. policy.
The pain that you -- an active nerd ;-) -- might be willing to accomodate and tolerate is very different from what most users are willing to tolerate. An QA on upgrades in the face of "pinning" is way way more complex.
Erasing unused packages has never been seriously attempted, mostly because the primary goal of installers and depsolvers is Upgrade! not otherwise.
73 de Jeff
