[opensuse-packaging] Shared Library Packaging Policy for alternate implementations?
Hi, The Shared Library Packaging Policy says that the name of a library package is to be derived from the library's SONAME. What if there is a compatible alternative implementation of the library? Of course it has the same SONAME. Reusing the same package name would result in version confusion though. Are there any recommendations for naming packages of such alternative implementations? cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le jeudi 05 juin 2008, à 10:20 +0200, Ludwig Nussel a écrit :
Hi,
The Shared Library Packaging Policy says that the name of a library package is to be derived from the library's SONAME. What if there is a compatible alternative implementation of the library? Of course it has the same SONAME. Reusing the same package name would result in version confusion though. Are there any recommendations for naming packages of such alternative implementations?
Do you have an example of this? I would expect the package names to be different because they come from different projects anyway. In Debian, an example is the howl compatibility layer of avahi, which is named libavahi-compat-howl0. Vincent -- Les gens heureux ne sont pas pressés. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Vincent Untz wrote:
Le jeudi 05 juin 2008, à 10:20 +0200, Ludwig Nussel a écrit :
Hi,
The Shared Library Packaging Policy says that the name of a library package is to be derived from the library's SONAME. What if there is a compatible alternative implementation of the library? Of course it has the same SONAME. Reusing the same package name would result in version confusion though. Are there any recommendations for naming packages of such alternative implementations?
Do you have an example of this? I would expect the package names to be different because they come from different projects anyway. In Debian, an example is the howl compatibility layer of avahi, which is named libavahi-compat-howl0.
openal vs openal-soft. Of course the name of the base package is different but the name of a library package depends only on the SONAME according to the policy. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 5 Jun 2008, Ludwig Nussel wrote:
The Shared Library Packaging Policy says that the name of a library package is to be derived from the library's SONAME. What if there is a compatible alternative implementation of the library? Of course it has the same SONAME. Reusing the same package name would result in version confusion though. Are there any recommendations for naming packages of such alternative implementations?
Hmm. I think I would add a suffix to the lib-package name, ala libopenal1 and libopenal1-alt . I think it's important that the SONAME derived string really is part of the rpmname, so libaltopenal1 would be worse. Otherwise follow the policy, especially regarding the contents of such packages (i.e. only DSOs). You probable need exception files for the checker. Though, if we could decide on the above Dirk probably can change his checker to ignore -* suffixes in package names. I think you should avoid "well known" suffixes like -dev, -devel, -doc and so on, though, to reduce confusion. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, 5 Jun 2008, Michael Matz wrote:
Hi,
On Thu, 5 Jun 2008, Ludwig Nussel wrote:
The Shared Library Packaging Policy says that the name of a library package is to be derived from the library's SONAME. What if there is a compatible alternative implementation of the library? Of course it has the same SONAME. Reusing the same package name would result in version confusion though. Are there any recommendations for naming packages of such alternative implementations?
Hmm. I think I would add a suffix to the lib-package name, ala libopenal1 and libopenal1-alt . I think it's important that the SONAME derived string really is part of the rpmname, so libaltopenal1 would be worse.
Yep, I agree.
Otherwise follow the policy, especially regarding the contents of such packages (i.e. only DSOs). You probable need exception files for the checker. Though, if we could decide on the above Dirk probably can change his checker to ignore -* suffixes in package names. I think you should avoid "well known" suffixes like -dev, -devel, -doc and so on, though, to reduce confusion.
Also remember to add Conflicts tags properly. Another variant is to use what gcc does for libstdc++ - the packages are named libstdc++41 libstdc++42 libstdc++43, etc., after the package version, but all provide libstdc++6 (the SONAME of the library) like Provides: libstdc++6 = %{version}-%{release} Obsoletes: libstdc++6 < %{version}-%{release} but of course they are not really alternatives but only compatible (newer) versions. Richard. -- Richard Guenther <rguenther@suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, 5 Jun 2008 at 15:29, Richard Guenther wrote:
Also remember to add Conflicts tags properly.
Isn't it enough that the two packages conflict "naturally" by containg a file with the same name and location but different content? I think a package shouldn't need to know that there exists an alternative for it, or it would be impossible for such alternatives to be added by a third party. cu Reinhard --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, Jun 05, 2008 at 04:03:17PM +0200, Reinhard Max wrote:
On Thu, 5 Jun 2008 at 15:29, Richard Guenther wrote:
Also remember to add Conflicts tags properly.
Isn't it enough that the two packages conflict "naturally" by containg a file with the same name and location but different content?
No, the solver doesn't see the conflict as the metadata doesn't contain file md5sums. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 5 Jun 2008, Reinhard Max wrote:
On Thu, 5 Jun 2008 at 15:29, Richard Guenther wrote:
Also remember to add Conflicts tags properly.
Isn't it enough that the two packages conflict "naturally" by containg a file with the same name and location but different content?
Usual problem. To determine file conflicts before actually installing you need the complete file lists in the repository metadata. And that is _extremely_ expensive (FACTORY has 12 million files, now calculate yourself, you need at least filenames and possibly some metadata, like size, mtime, md5sum). So we usually don't have filelist, except for some subdirectories. But then we rely on proper conflict tags ...
I think a package shouldn't need to know that there exists an alternative for it, or it would be impossible for such alternatives to be added by a third party.
... so in theory you are completely right, but in practice we can't currently rely on file conflicts to be handled properly. There are some ways out of this, e.g. only downloading filelists for packages in question, but nothing of that is designed, much less implemented. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Richard Guenther wrote:
Also remember to add Conflicts tags properly.
Another variant is to use what gcc does for libstdc++ - the packages are named libstdc++41 libstdc++42 libstdc++43, etc., after the package version, but all provide libstdc++6 (the SONAME of the library) like
Provides: libstdc++6 = %{version}-%{release} Obsoletes: libstdc++6 < %{version}-%{release}
but of course they are not really alternatives but only compatible (newer) versions.
That is not really applicable to openal-soft. openal-soft is no successor of openal. Both projects are developed in parallel atm. So openal-soft basically conflicts with openal (any version) but at the same time should provide it so Recommends/Requires are also satisfied with openal-soft. rpm didn't like packages that provide and conflict the same thing last time I checked though. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 5 Jun 2008, Ludwig Nussel wrote:
That is not really applicable to openal-soft. openal-soft is no successor of openal. Both projects are developed in parallel atm. So openal-soft basically conflicts with openal (any version) but at the same time should provide it so Recommends/Requires are also satisfied with openal-soft. rpm didn't like packages that provide and conflict the same thing last time I checked though.
Yeah, that's still the case. And probably won't ever change according to the rpm author. That was also the problem with the theming packages. Very unfortunate. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Thu, Jun 05, 2008 at 04:29:33PM +0200, Michael Matz wrote:
On Thu, 5 Jun 2008, Ludwig Nussel wrote:
[...] with openal-soft. rpm didn't like packages that provide and conflict the same thing last time I checked though.
Yeah, that's still the case. And probably won't ever change according to the rpm author. That was also the problem with the theming packages.
Hmm, I'm nur sure what you mean here. Sure, conflicts work with provides, but I'm not aware of any discussion about that. What was discussed was weather obsoletes should work with provides, currently they don't (rpm-4 upstream style), in rpm-5 they do. Cheers, Michael. -- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Hi, On Thu, 5 Jun 2008, Michael Schroeder wrote:
On Thu, Jun 05, 2008 at 04:29:33PM +0200, Michael Matz wrote:
On Thu, 5 Jun 2008, Ludwig Nussel wrote:
[...] with openal-soft. rpm didn't like packages that provide and conflict the same thing last time I checked though.
Yeah, that's still the case. And probably won't ever change according to the rpm author. That was also the problem with the theming packages.
Hmm, I'm nur sure what you mean here. Sure, conflicts work with provides, but I'm not aware of any discussion about that. What was discussed was weather obsoletes should work with provides, currently they don't (rpm-4 upstream style), in rpm-5 they do.
No, I mean the problems the theming packages have. You can install only one of a set, that set is unknown, and the set members don't know about each other. To express this it would be ideal if all of them provide X and also conflict with X, but that isn't allowed by rpm. Ciao, Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (6)
-
Ludwig Nussel -
Michael Matz -
Michael Schroeder -
Reinhard Max -
Richard Guenther -
Vincent Untz