RFC: Soname in rpm name

[Jeff Johnson]

Michael Schwendt wrote:

>On Mon, 24 Jan 2005 07:13:38 -0500, Jeff Johnson wrote:
>
>  
>
>>Aurelien Bompard wrote:
>>
>>    
>>
>>>Jeff Johnson wrote:
>>> 
>>>
>>>      
>>>
>>>>Try with rpm -i.
>>>>   
>>>>
>>>>        
>>>>
>>>Yeah OK. How about something that would be understood by depsolvers then ?
>>> 
>>>
>>>      
>>>
>>Depsolvers (at least correctly written ones) use Provides:, not Name:, 
>>for choosing
>>what packages to install.
>>    
>>
>
>We need to support what we do have right now. And neither Yum nor
>"rpm -Uvh" would _not_ upgrade package libfoo to a newer libfoo.
>

 From multiply installed rpm -i? Sure, no application gets that right.

I question "need" however, as "Don't do that." is workable alternative many
years now, and there are other techiques, like readline43 and compat-db, 
that
are sufficient for the MUSTHAVE problems.

And after incompatible sonames, comes issues with --relocate that noone has
ever attempted to solve the upgrade cases for. <shrug>

But I'm sure the java heads will break *.rpm packaging with --relocate for
their *.jar files if/when they discover --relocate. Again <shrug>, 
there's invariably
something along the lines of "Don't do that." that can be devised.

>  
>
>>The only reason for ornamenting the package name with gunk is to attempt 
>>to provide
>>a clue of differences through primitive HTTP/FTP browser GUI's.
>>
>>    
>>
>>>This must be a common problem, isn't it ? What do you do when an important
>>>library changes its soname in the next version ?
>>> 
>>>
>>>      
>>>
>>Usually a soname is slam-dunked, the library and every package that uses 
>>the library
>>are changed at the same time. That works for the distro itself.
>>    
>>
>
>Does it? Then why do we have packages like openmotif21 and openmotif,
>libpng10, libpng10-devel, libpng, libpng-devel in the distro?
>  
>

Because while it works for the distro, slam dunking does not work for
3rd party packing. In fact, slam-dunking is not gonna work for 2nd party
packaging like Fedora Extras. What will happen instead (imho) is that 
library
sonames simply won't change, even if they should.

>It's not different from what we've done in fedora.us packages.
>Include parts of the soname version in the package name to make
>multiple library versions coexist nicely, i.e. also during upgrades.
>Package resolvers pick the right package based on automatic
>Provides/Requires.
>  
>

So put sonames into package names if that floats your fedora.us boat. 
Sooner or later you
will run into kernel file system imposed limits on package file names. 
<shrug>

73 de Jeff