[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: RFC: Soname in rpm name

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

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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]