Bug#947323: libcap-ng: Please install libs back into /usr/lib/ when usrmerge arrives
Hi Helmut, On 14.11.2023 19:36, Helmut Grohne wrote: > user helm...@debian.org > usertags -1 + dep17m2 > thanks > > On Tue, Nov 14, 2023 at 12:52:39PM +0100, Helmut Grohne wrote: >> Hence, we are good to go. I do not expect libcap-ng to be uploaded to >> bookworm-backports and therefore changed the paths directly in the >> attached patch. This patch should not be uploaded to bookworm-backports. >> If that's relevant to you, consider using dh_movetousr instead. Also >> keep in mind that restructuring changes (such as libcap-ng0t64) should >> be uploaded to experimental first to let dumat analyze your change for >> possible problems. > > I'm sorry. Further testing has revealed that I failed to remove the /lib > directory from the package. We really need to get rid of it, because > dpkg is not equipped to deal with symlink vs directory conflicts. Here > is an updated patch. > Thanks for the patch, though I already have a commit with the same changes laying around [1], I have been unsure when to apply it. I guess the time is nearing. As for the backporting, I at least have no intention of backporting this package. Upstream has talked about a new release 'soon', I intend to include this change at the same time. Regardless of the new release, it will be uploaded by the end of this year at the latest. Håvard [1] https://salsa.debian.org/debian/libcap-ng/-/commit/9c6991a7f198c486c38e4a5ddf2e0142d4f64564
Bug#947323: libcap-ng: Please install libs back into /usr/lib/ when usrmerge arrives
user helm...@debian.org usertags -1 + dep17m2 thanks On Tue, Nov 14, 2023 at 12:52:39PM +0100, Helmut Grohne wrote: > Hence, we are good to go. I do not expect libcap-ng to be uploaded to > bookworm-backports and therefore changed the paths directly in the > attached patch. This patch should not be uploaded to bookworm-backports. > If that's relevant to you, consider using dh_movetousr instead. Also > keep in mind that restructuring changes (such as libcap-ng0t64) should > be uploaded to experimental first to let dumat analyze your change for > possible problems. I'm sorry. Further testing has revealed that I failed to remove the /lib directory from the package. We really need to get rid of it, because dpkg is not equipped to deal with symlink vs directory conflicts. Here is an updated patch. Helmut diff --minimal -Nru libcap-ng-0.8.3/debian/changelog libcap-ng-0.8.3/debian/changelog --- libcap-ng-0.8.3/debian/changelog2022-06-23 07:22:33.0 +0200 +++ libcap-ng-0.8.3/debian/changelog2023-11-14 19:31:43.0 +0100 @@ -1,3 +1,10 @@ +libcap-ng (0.8.3-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Move libraries to /usr. Closes: #947323 + + -- Helmut Grohne Tue, 14 Nov 2023 19:31:43 +0100 + libcap-ng (0.8.3-1) unstable; urgency=medium * New upstream release. Closes: #1004519 diff --minimal -Nru libcap-ng-0.8.3/debian/libcap-ng0.dirs libcap-ng-0.8.3/debian/libcap-ng0.dirs --- libcap-ng-0.8.3/debian/libcap-ng0.dirs 2022-06-23 07:22:33.0 +0200 +++ libcap-ng-0.8.3/debian/libcap-ng0.dirs 2023-11-14 19:31:37.0 +0100 @@ -1,2 +1 @@ -lib usr/lib diff --minimal -Nru libcap-ng-0.8.3/debian/libcap-ng0.install libcap-ng-0.8.3/debian/libcap-ng0.install --- libcap-ng-0.8.3/debian/libcap-ng0.install 2022-06-23 07:22:33.0 +0200 +++ libcap-ng-0.8.3/debian/libcap-ng0.install 2023-11-14 19:31:24.0 +0100 @@ -1 +1 @@ -lib/*/lib*.so.* +usr/lib/*/lib*.so.* diff --minimal -Nru libcap-ng-0.8.3/debian/rules libcap-ng-0.8.3/debian/rules --- libcap-ng-0.8.3/debian/rules2022-06-23 07:22:33.0 +0200 +++ libcap-ng-0.8.3/debian/rules2023-11-14 19:31:24.0 +0100 @@ -34,12 +34,6 @@ done find $(CURDIR)/debian/tmp -name *.la -delete - mkdir -p $(CURDIR)/debian/tmp/lib/$(DEB_HOST_MULTIARCH) && \ - mv $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/lib*.so.0* $(CURDIR)/debian/tmp/lib/$(DEB_HOST_MULTIARCH)/; \ - rm debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libcap-ng.so; \ - ln -s ../../../lib/$(DEB_HOST_MULTIARCH)/libcap-ng.so.0.0.0 debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libcap-ng.so; \ - rm debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libdrop_ambient.so; \ - ln -s ../../../lib/$(DEB_HOST_MULTIARCH)/libdrop_ambient.so.0.0.0 debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libdrop_ambient.so; \ override_dh_auto_test: for V in $(PY3VERS); do \
Bug#947323: libcap-ng: Please install libs back into /usr/lib/ when usrmerge arrives
Control: user helm...@debian.org Control: usertags -1 + dep17m2 Control: tags -1 + patch On Tue, Dec 24, 2019 at 11:52:56AM -0500, Boyuan Yang wrote: > With the progress of usrmerge, it should be reasonable to move libcap-ng so > files back to /usr/lib/ when usrmerge becomes the default of Debian > installation. (See https://bugs.debian.org/829126 and > https://bugs.debian.org/828992 for the original reason of moving the library > into /lib). The file move moratorium has now been delegated to https://wiki.debian.org/UsrMerge. We now can move, but need to be careful. https://subdivi.de/~helmut/dep17.html lists a few problem classes to watch out for. If we were to rename libcap-ng0 to libcap-ng0t64 as part of https://wiki.debian.org/ReleaseGoals/64bit-time, that would cause a file loss scenario (DEP17 P1), but it is listed as not-affected. Most other problems do not apply. Multiarch shared file loss (P7) does not apply, because the libraries are installed to architecture-dependent paths. I locally verified that the change does not impact filesystem bootstrap. Since no udebs are built, the debian-installer is not affected (P10). Hence, we are good to go. I do not expect libcap-ng to be uploaded to bookworm-backports and therefore changed the paths directly in the attached patch. This patch should not be uploaded to bookworm-backports. If that's relevant to you, consider using dh_movetousr instead. Also keep in mind that restructuring changes (such as libcap-ng0t64) should be uploaded to experimental first to let dumat analyze your change for possible problems. Helmut diff --minimal -Nru libcap-ng-0.8.3/debian/changelog libcap-ng-0.8.3/debian/changelog --- libcap-ng-0.8.3/debian/changelog2022-06-23 07:22:33.0 +0200 +++ libcap-ng-0.8.3/debian/changelog2023-11-14 12:42:31.0 +0100 @@ -1,3 +1,10 @@ +libcap-ng (0.8.3-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Move libraries to /usr. Closes: #-1 + + -- Helmut Grohne Tue, 14 Nov 2023 12:42:31 +0100 + libcap-ng (0.8.3-1) unstable; urgency=medium * New upstream release. Closes: #1004519 diff --minimal -Nru libcap-ng-0.8.3/debian/libcap-ng0.install libcap-ng-0.8.3/debian/libcap-ng0.install --- libcap-ng-0.8.3/debian/libcap-ng0.install 2022-06-23 07:22:33.0 +0200 +++ libcap-ng-0.8.3/debian/libcap-ng0.install 2023-11-14 12:42:23.0 +0100 @@ -1 +1 @@ -lib/*/lib*.so.* +usr/lib/*/lib*.so.* diff --minimal -Nru libcap-ng-0.8.3/debian/rules libcap-ng-0.8.3/debian/rules --- libcap-ng-0.8.3/debian/rules2022-06-23 07:22:33.0 +0200 +++ libcap-ng-0.8.3/debian/rules2023-11-14 12:42:13.0 +0100 @@ -34,12 +34,6 @@ done find $(CURDIR)/debian/tmp -name *.la -delete - mkdir -p $(CURDIR)/debian/tmp/lib/$(DEB_HOST_MULTIARCH) && \ - mv $(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/lib*.so.0* $(CURDIR)/debian/tmp/lib/$(DEB_HOST_MULTIARCH)/; \ - rm debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libcap-ng.so; \ - ln -s ../../../lib/$(DEB_HOST_MULTIARCH)/libcap-ng.so.0.0.0 debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libcap-ng.so; \ - rm debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libdrop_ambient.so; \ - ln -s ../../../lib/$(DEB_HOST_MULTIARCH)/libdrop_ambient.so.0.0.0 debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)/libdrop_ambient.so; \ override_dh_auto_test: for V in $(PY3VERS); do \
Bug#947323: libcap-ng: Please install libs back into /usr/lib/ when usrmerge arrives
Source: libcap-ng Severity: normal Version: 0.7.9-2.1 Dear libcap-ng maintainer, With the progress of usrmerge, it should be reasonable to move libcap-ng so files back to /usr/lib/ when usrmerge becomes the default of Debian installation. (See https://bugs.debian.org/829126 and https://bugs.debian.org/828992 for the original reason of moving the library into /lib). -- Regards, Boyuan Yang signature.asc Description: This is a digitally signed message part
