RFC: Soname in rpm name
Jeff Johnson
n3npq at nc.rr.com
Mon Jan 24 12:33:24 UTC 2005
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
More information about the devel
mailing list