I've been unable to locate any packaging guidelines/requirements that indicate that a source package providing shared libraries should have those shared libraries packaged into a sub-package with the major version of library appended to the sub-package name (i.e. libfoo1, libfoo2, etc.) -- to facilitate concurrent installation of the differing major versions of the library.
Is there no such guideline/requirement?
"BJM" == Brian J Murrell brian@interlinx.bc.ca writes:
BJM> I've been unable to locate any packaging guidelines/requirements BJM> that indicate that a source package providing shared libraries BJM> should have those shared libraries packaged into a sub-package with BJM> the major version of library appended to the sub-package name BJM> (i.e. libfoo1, libfoo2, etc.) -- to facilitate concurrent BJM> installation of the differing major versions of the library.
There is no such guideline as far as I know.
- J<
Yeah, I'm coming to that conclusion also.
It's a pity though. As not requiring it is going to prevent the future need (some day) of having both major versions installed to bridge a major version transition gap while software catches up to using the new major version of the library.
"BJM" == Brian J Murrell brian@interlinx.bc.ca writes:
BJM> It's a pity though.
I don't agree; to do so would be mostly useless complexity. You are certainly welcome to break libraries out in your packages, and there are good reasons for doing so which are covered in the guidelines. (Hence the number of "-libs" packages.) But it is not generally required.
BJM> As not requiring it is going to prevent the future need (some day) BJM> of having both major versions installed to bridge a major version BJM> transition gap while software catches up to using the new major BJM> version of the library.
And yet we do that all the time.
- J<
And yet we do that all the time.
How can you replace libfoo-1.00 with libfoo-2.0.0 when some software has not updated to libfoo-2.0.0's ABI breaking changes yet? Updating libfoo-1.0.0 to libfoo-2.0.0 will remove the libfoo.1{,.0.0} shared libs and software still needing them will break.
"BJM" == Brian J Murrell brian@interlinx.bc.ca writes:
BJM> How can you replace libfoo-1.00 with libfoo-2.0.0 when some BJM> software has not updated to libfoo-2.0.0's ABI breaking changes BJM> yet?
Create a libfoo1 package, have it include the necessary library files (and perhaps a -devel subpackage if you wish for things to compile against it) and update the base libfoo package to the new version.
We do this all the time. Some packages utilize an older naming scheme involving a "compat-" prefix but that shouldn't be used these days.
- J<
On Mon, Aug 19, 2019 at 7:33 PM Jason L Tibbitts III tibbs@math.uh.edu wrote:
"BJM" == Brian J Murrell brian@interlinx.bc.ca writes:
BJM> How can you replace libfoo-1.00 with libfoo-2.0.0 when some BJM> software has not updated to libfoo-2.0.0's ABI breaking changes BJM> yet?
Create a libfoo1 package, have it include the necessary library files (and perhaps a -devel subpackage if you wish for things to compile against it) and update the base libfoo package to the new version.
We do this all the time. Some packages utilize an older naming scheme involving a "compat-" prefix but that shouldn't be used these days.
We also strive to maintain ABI stability on stable releases, so in theory this happens during major upgrades when compat packages are not involved.
Dridi
Create a libfoo1 package, have it include the necessary library files (and perhaps a -devel subpackage if you wish for things to compile against it) and update the base libfoo package to the new version.
Ok. So you can/do create a libfoo$major subpackage at times when it's necessary. It's just not required/recommended to always package libs that way. Fair enough.
I guess it just seems to me that it would be more consistent/less surprising to have libraries always follow this scheme rather than to do so only intermittently. But that's just my 2 cents.
On Tue, Aug 20, 2019, 13:05 Brian J. Murrell brian@interlinx.bc.ca wrote:
Create a libfoo1 package, have it include the necessary library files (and perhaps a -devel subpackage if you wish for things to compile against it) and update the base libfoo package to the new version.
Ok. So you can/do create a libfoo$major subpackage at times when it's necessary. It's just not required/recommended to always package libs that way. Fair enough.
I guess it just seems to me that it would be more consistent/less surprising to have libraries always follow this scheme rather than to do so only intermittently. But that's just my 2 cents.
I think it comes down to a different philosophy regarding distribution development.
In fedora, the default mode of operation is to move all consumers of a library to the latest version, if possible (this usually happens only in the development /master / rawhide branch). Only of that's not possible easily or in a timely manner, a compatibility package for the older version of the library is introduced. These are then often dropped again as soon as all dependent projects have migrated to the new library version.
If you think of the newest version being the default, it makes sense that it doesn't contain the library version in its package name.
Fabio
_______________________________________________
packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....
On Mon, Aug 19, 2019 at 5:54 PM Brian J. Murrell brian@interlinx.bc.ca wrote:
I've been unable to locate any packaging guidelines/requirements that indicate that a source package providing shared libraries should have those shared libraries packaged into a sub-package with the major version of library appended to the sub-package name (i.e. libfoo1, libfoo2, etc.) -- to facilitate concurrent installation of the differing major versions of the library.
Is there no such guideline/requirement?
Sounds more like the Debian way of packaging shared objects, but it doesn't solve the resulting conflict on libfoo.so in devel packages.
There is a guideline for a -lib or -libs sub-package if the libraries may be usable without the whole package, if I remember correctly.
Dridi
Sounds more like the Debian way of packaging shared objects, but it doesn't solve the resulting conflict on libfoo.so in devel packages.
There's no conflict in -devel packages. libfoo.so is a symlink to the real libfoo.so.$major and only one -devel is allowed to be installed at a time and it usually matches the latest libfoo$major package.
There is a guideline for a -lib or -libs sub-package if the libraries may be usable without the whole package, if I remember correctly.
Indeed. but it doesn't seem to address multiple major version library cohabitation -- for the purposes of bridging library major version updates (i.e. ABI breakage) where other packages depending on the lib might not have been updated to the new ABI.
On Mon, Aug 19, 2019 at 7:29 PM Brian J. Murrell brian@interlinx.bc.ca wrote:
Sounds more like the Debian way of packaging shared objects, but it doesn't solve the resulting conflict on libfoo.so in devel packages.
There's no conflict in -devel packages. libfoo.so is a symlink to the real libfoo.so.$major and only one -devel is allowed to be installed at a time and it usually matches the latest libfoo$major package.
Well, in this case I don't consider that it will "facilitate concurrent installation of the differing major versions of the library" if I can't target both libraries when I locally build (read: not in mock) pieces of software against both sonames.
And this has always bothered me with compat packages, because having to target both OpenSSL 1.0 and 1.1 force me to `dnf trampoline` between both devel packages.
Dridi
On Mon, 19 Aug 2019 19:09:19 -0000, Brian J. Murrell wrote:
Sounds more like the Debian way of packaging shared objects, but it doesn't solve the resulting conflict on libfoo.so in devel packages.
There's no conflict in -devel packages. libfoo.so is a symlink to the real libfoo.so.$major and only one -devel is allowed to be installed at a time and it usually matches the latest libfoo$major package.
That is an implict conflict between the packages nevertheless, since it results in a conflict, if one package is installed already and you need to install the other package. Of course, you can avoid the conflict manually by removing either package from the installation, but having to do that is annoying.
That is an implict conflict between the packages nevertheless, since it results in a conflict, if one package is installed already and you need to install the other package. Of course, you can avoid the conflict manually by removing either package from the installation, but having to do that is annoying.
Agreed, and I already replied to that.
Now regarding the original question, we already have per-libraries virtual provides, we could generate more to match Debian packaging guidelines:
Before:
$ rpm -qP varnish | grep lib libvarnishapi.so.2()(64bit) libvarnishapi.so.2(LIBVARNISHAPI_2.0)(64bit)
After:
$ rpm -qP varnish | grep lib libvarnishapi2 = 6.1.1-4.fc30 libvarnishapi2.x86_64 = 6.1.1-4.fc30 libvarnishapi.so.2()(64bit) libvarnishapi.so.2(LIBVARNISHAPI_2.0)(64bit)
So one could `dnf install` or BuildRequires libvarnishapi2:
https://packages.debian.org/buster/libvarnishapi2
Now my worry would be Debian-like compatibility at the expense of metadata bloat.
Dridi
The point is that we typically don't want this situation to happen, so if there is released libfoo 2.0.0, we prefer to migrate all the packages which depends on the libfoo to support the latest version. This typically happens in Rawhide.
If some dependency does not support the libfoo 2.0.0 for some reasons yet, we use temporarily either libfoo1 or compat-libfoo packages as was discussed on the other places of this thread. Also we try to collaborate with upstream to fix the compatibility.
Vít
Dne 19. 08. 19 v 19:36 Brian J. Murrell napsal(a):
I've been unable to locate any packaging guidelines/requirements that indicate that a source package providing shared libraries should have those shared libraries packaged into a sub-package with the major version of library appended to the sub-package name (i.e. libfoo1, libfoo2, etc.) -- to facilitate concurrent installation of the differing major versions of the library.
Is there no such guideline/requirement? _______________________________________________ packaging mailing list -- packaging@lists.fedoraproject.org To unsubscribe send an email to packaging-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject....
packaging@lists.fedoraproject.org
-
Brian J. Murrell -
Dridi Boukelmoune -
Fabio Valentini -
Jason L Tibbitts III -
Michael Schwendt -
Vít Ondruch