RFC: Soname in rpm name

Alexandre Oliva aoliva at redhat.com
Tue Jan 25 09:19:00 UTC 2005

On Jan 25, 2005, Jeff Johnson <n3npq at nc.rr.com> wrote:

> Alexandre Oliva wrote:
>> 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.

Not the same pinning.  I'm talking about adding a bit that would tell
whether a particular package was requested by the user or brought in
just to satisfy a dependency of another package.  Packages of the
latter group that no longer have any dependency in the database may be
garbage collected.  Packages of the former group shouldn't.

> 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.

We're talking about different sorts of pinning.  Please re-read my
suggestion with the paragraph I wrote above in mind, and hopefully it
will make sense, and not seem too complicated of a concept.

> Erasing unused packages has never been seriously attempted, mostly
> because the primary goal of installers and depsolvers is
>     Upgrade!
> not otherwise.

Yeah, but this discussion got into the topic of removing unused
packages.  A number of different heuristics were suggested, but all of
them were not more than heuristics.  What I suggest (marking packages
in the database as having been brought in only to satisfy
dependencies) would enable such packages to be easily located and
removed when other packages that caused them to be brought in are

Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

More information about the fedora-devel-list mailing list