RFC: Soname in rpm name

Jeff Johnson n3npq at nc.rr.com
Tue Jan 25 06:23:32 UTC 2005


Alexandre Oliva wrote:

>On Jan 24, 2005, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
>
>  
>
>>On Mon, Jan 24, 2005 at 03:05:29PM -0200, Alexandre Oliva wrote:
>>    
>>
>>>On Jan 24, 2005, Ralf Ertzinger <fedora-devel at camperquake.de> wrote:
>>>      
>>>
>
>  
>
>>>>The problem with this is that RPM does not indicate whether a package has
>>>>"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.
>>>>        
>>>>
>>>Could we perhaps add such a flag to the rpm database?  Then the
>>>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




More information about the devel mailing list