Bug#1003653: Revision of removal of rename.ul from package util-linux
On Sat, 09 Apr 2022 19:00:37 +0200, Helmut Grohne wrote: > Chris proposes to transition /usr/bin/rename from the perl API to the > util-linux API. [..] > Dom (or whoever maintains perl's rename now), would you agree to release > the /usr/bin/rename name to use it for util-linux' implementation > retaining prename for the perl implementation? (The "whoever" was and is the Debian Perl Group :)) I'd like to quote Chris and Dom from #114 in this bug: On Tue, Jan 25, 2022 at 09:16:25AM +0100, Chris Hofstaedtler wrote: > A very valid way of closing this discussion is saying "our > (Perl) /usr/bin/rename is great, people should use that". That's the conclusion I came to when I looked at this at the point of packaging rename separately. There doesn't seem to be any benefit to changing this command line interface in Debian at this stage even though I don't think it should have been there in the first place. Dominic I think this conclusion still holds. Some additional thoughts: * Shipping u-l's rename as /usr/bin/rename.ul might be nice for users who want to use it and are already used to this name. * Switching /usr/bin/rename from perl's rename to u-l's rename will break interactive and scripted user experience. * A Conflicts of a new util-linux-$something against file-rename will be painful for users. * Personally I very much prefer compatibility with Debian's history over compatibility with Fedora. * Side note: "releasing the /usr/bin/rename name" is an interesting framing. Cheers, gregor -- .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe `- signature.asc Description: Digital Signature
Bug#994388: Bug#1008489: dpkg: postinst should not warn about Debian's default (and soon only supported) filesystem layout
On Sat, 2022-04-09 at 11:01 -0700, Sean Whitton wrote: > Okay I see. > > To answer your question, then, the ctte has not even discussed the > relevance of warnings to derivatives. Well, the ctte has mostly discussed things in private. I have no idea and it's not possible to comment on what the ctte might or might not have discussed and might or might not have missed. Impact on derivatives seems an obvious topic to me. > I can't speak for everyone, but I > suspect that we would not consider this NMU to be in line with our > existing decisions. I look forward to seeing discussion on this or a summary of previous private discussion results. Ansgar
Bug#994388: Bug#1008489: proposed diff for dpkg 1.21.7+nmu1
On Sat, 2022-04-09 at 10:59 -0700, Sean Whitton wrote: > On Sat 09 Apr 2022 at 11:50am +02, Ansgar wrote: > > I've prepared a patch for the current issue. See the attached proposed > > NMU diff. I've limited it to minimal changes. > > I don't understand. The warning is already no longer emitted on > Debian? Debian is used as a basis by derivative distributions where it is still emitted. Most derivatives will likely follow Debian (unless you expect a significant number of them to have resources to fork and maintain packages for continued split-/usr support). I think it is reasonable for Debian packages to behave reasonably on derivatives as well. In this case that means dpkg should not emit a warning by default on derivatives either. Ansgar
Bug#994388: Bug#1008489: proposed diff for dpkg 1.21.7+nmu1
Hello, On Sat 09 Apr 2022 at 11:50am +02, Ansgar wrote: > Hi, > > I've prepared a patch for the current issue. See the attached proposed > NMU diff. I've limited it to minimal changes. I don't understand. The warning is already no longer emitted on Debian? -- Sean Whitton
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi Dom and Chris, Chris proposes to transition /usr/bin/rename from the perl API to the util-linux API. On Thu, Apr 07, 2022 at 01:04:54PM +0200, Chris Hofstaedtler wrote: > I see two clear options: [...] > B) Finish the very old migration. Have util-linux(-extra) ship >/usr/bin/rename; perl rename can be prename/file-rename as today, >but would need to drop the update-alternatives symlink; versioned >Conflicts/Provides/Replaces would probably be needed. I would also >suggest having no binary package ship /usr/bin/rename for one >release. > > This is also a very clear option: > > - All code can in the future assume /usr/bin/rename to have the same > interface across distributions. Even Debian code. > - Does not need update-alternatives in an Essential package (= no > postinst fragment). > Less of an issue if /usr/bin/rename will be in util-linux-extra. > - One thing less in src:util-linux that needs dh-exec (which is > orphaned and I want to get rid of). > - Debian can ship both variants under "nice enough" names. Dom (or whoever maintains perl's rename now), would you agree to release the /usr/bin/rename name to use it for util-linux' implementation retaining prename for the perl implementation? A little background (for newly added participants): We have two conflicting APIs for /usr/bin/rename. The perl API has historical precedent in Debian. The util-linux API tends to be used more widely accross other Linux distributions (in particular Fedora). We cannot have /usr/bin/rename both be compatible with old versions of Debian and current versions of Fedora. That leaves us in the difficult spot where we get to decide which compatibility to keep. Chris essentially wants the util-linux implementation to either not be shipped at all or filling the /usr/bin/rename spot. So now, we're asking the perl side for their view on this. If /usr/bin/rename is to be transitioned from perl to util-linux, I think we should have a proper announcement on debian-devel@l.d.o or better d-d-a before doing it, but getting the input from the perl side seems to be a prerequisite. Helmut
Bug#1003653: Revision of removal of rename.ul from package util-linux
* Matthew Vernon [220409 16:12]: > On 09/04/2022 14:59, Chris Hofstaedtler wrote: [..] > > I know we all want this TC issue to be resolved. But I do not want > > to end up shipping rename.ul indefinitely. > > I'm still not sure what harm occurs from doing so? I gave some technical reasons why I do not want to, upthread. I would also request that my decision is respected - regardless if I give technical or social reasons for it, or not. Maintainers have ideas and/or plans how the packages they maintain should look like, and which functions they should provide. Unless the TC wants to rule on a maintainer override, this should be enough. To add a social reason: if rename from src:util-linux is again shipped under a name other than "rename", I am very sure people will (re-)open bugs about "missing" update-alternatives setup to switch incompatible "rename" interfaces. And probably complain again on mailing lists and/or in LWN comments if such a bug gets closed. I'll spare you my ideas on what this does to the motivation of individual maintainers. Anyway. I do not see what bringing back "rename.ul" at this point helps anyone. The compatibility ship has sailed. Companies and institutions relying on "rename.ul" in future distribution versions certainly have the resources of building their own "just-rename.ul-from-util-linux.deb" which can work across Debian (and derivatives) versions. I'm up for making changes towards a simpler future. Chris
Bug#994388: dpkg currently warning about merged-usr systems
Hello, On Sat 09 Apr 2022 at 02:52pm +02, Wouter Verhelst wrote: > On a side note, the dpkg maintainer replied to my message, dropping the > -ctte Cc, wherein he claims that the warning has been removed: Yes, it has been removed for some days now -- sorry, thought that was more widely known. > https://lists.debian.org/debian-dpkg/2022/04/msg7.html Thanks for the link. -- Sean Whitton
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hi, On 09/04/2022 14:59, Chris Hofstaedtler wrote: I was not planning on doing that: stable already does not have /usr/bin/rename.ul. People were asking for it to be restored before the stable release, though, I think? #966468 was opened against version 2.36-1 back in July 2020. Given rename.ul is not in stable (bullseye), I do not think we should do this. From a compatibility point of view, we do not win anything. At this point, we are more talking about shipping a new program in a new place, than continuing to ship an existing program. I disagree; we have historically shipped rename.ul, we didn't in stable (against the wishes of at least some of our users), but I don't think that means that restoring it again would be "shipping a new program in a new place" in a meaningful sense. If we were talking about all of this before the stable release, I would be a lot more open about other options. But by now almost two years have passed since the change, and bullseye is out for ~ 9 months. Issues are slow to get to the TC, and the TC is often slow to resolve them; I think "escalate to the TC rapidly or the status quo ante will prevail" is not a line I want to encourage. I know we all want this TC issue to be resolved. But I do not want to end up shipping rename.ul indefinitely. I'm still not sure what harm occurs from doing so? Regards, Matthew
Bug#1003653: Revision of removal of rename.ul from package util-linux
Hello Christoph, * Christoph Berg [220407 15:11]: > Re: Chris Hofstaedtler > > B) Finish the very old migration. Have util-linux(-extra) ship > >/usr/bin/rename; perl rename can be prename/file-rename as today, > >but would need to drop the update-alternatives symlink; versioned > >Conflicts/Provides/Replaces would probably be needed. I would also > >suggest having no binary package ship /usr/bin/rename for one > >release. > > What name would you use in util-linux-extra for the time of the one > release where no package ships /usr/bin/rename? /usr/bin/rename.ul > seems most sensible to me here, which would also match the status > before starting a migration. I was not planning on doing that: stable already does not have /usr/bin/rename.ul. > > Personally I am leaning towards option A) - mostly because we > > are/were already spending a lot more time on mails than what I think > > the work of option B) would entail. Also I believe the CTTE does not > > want to do any of this fine grainted technical detail design work. > > We don't want to dictate *how* this should be resolved, but we are > interested in *having* it resolved, and A) isn't that. > > To me, the plausible way forward here seems to be this: > > * Reintroduce it as /usr/bin/rename.ul in util-linux-extra > * Have u-l-e be pseudo-essential for one release > * At this point the TC issue is resolved > * Potentially work with the perl-rename maintainers to transition to a > different layout of the two utilities. That's then indeed outside > the scope of the TC. Given rename.ul is not in stable (bullseye), I do not think we should do this. From a compatibility point of view, we do not win anything. At this point, we are more talking about shipping a new program in a new place, than continuing to ship an existing program. If we were talking about all of this before the stable release, I would be a lot more open about other options. But by now almost two years have passed since the change, and bullseye is out for ~ 9 months. I know we all want this TC issue to be resolved. But I do not want to end up shipping rename.ul indefinitely. Chris
Bug#994388: dpkg currently warning about merged-usr systems
On Sat, 2022-04-09 at 14:52 +0200, Wouter Verhelst wrote: > On a side note, the dpkg maintainer replied to my message, dropping > the -ctte Cc, wherein he claims that the warning has been removed: > > https://lists.debian.org/debian-dpkg/2022/04/msg7.html So one of the statements there is: | The TC ruling stated that Debian supports for now both layouts So maybe the dpkg maintainer just missed that we decided to only support merged-/usr starting with bookworm? Guillem, please read https://bugs.debian.org/978636#178, relevant part quoted below: |The Technical Committee resolves that Debian 'bookworm' should |support only the merged-usr root filesystem layout, dropping support |for the non-merged-usr layout. Maybe the misunderstanding will be resolved with this. Ansgar
Bug#994388: dpkg currently warning about merged-usr systems
On Fri, Apr 08, 2022 at 12:07:25PM -0700, Sean Whitton wrote:
> Hello Wouter,
>
> On Fri 08 Apr 2022 at 09:36AM +02, Wouter Verhelst wrote:
>
> > Given that, in case the dpkg maintainer chooses to remain silent
> > again, I believe the only way forward is for the TC to recommend a GR
> > under §4.2.1 of the consitution.
>
> Perhaps there is some appropriate GR that at some point it will be
> appropriate for the ctte to propose, but not one with the same text as
> one of our merged-/usr decisions already issued -- that doesn't make
> much constitutional sense, I think.
Well, I think it would -- the TC can always say "we want to get wider
input", and a GR is a proper way to do so, even if the GR is about the
exact thing the TC previously decided on (though that of course doesn't
need to be the case). Perhaps if there is a clearer project-wide
consensus about this, the dpkg maintainer might be convinced?
But that was just a thought, feel free to ignore it :-)
On a side note, the dpkg maintainer replied to my message, dropping the
-ctte Cc, wherein he claims that the warning has been removed:
https://lists.debian.org/debian-dpkg/2022/04/msg7.html
I didn't check any of the claims in his message, but it seems relevant
information.
--
w@uter.{be,co.za}
wouter@{grep.be,fosdem.org,debian.org}
Bug#994388: proposed diff for dpkg 1.21.7+nmu1
Hi,
I've prepared a patch for the current issue. See the attached proposed
NMU diff. I've limited it to minimal changes.
Is this something the technical committee finds acceptable?
Ansgar
From 2569c0aca93f2f0d7f5521c3158ed077f206ce0a Mon Sep 17 00:00:00 2001
From: Ansgar
Date: Sat, 9 Apr 2022 11:14:40 +0200
Subject: [PATCH] dpkg.postinst: Remove warning about merged-/usr. Closes:
#1008489
---
debian/changelog | 7 +++
debian/dpkg.postinst | 38 --
2 files changed, 7 insertions(+), 38 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 6375989..a316609 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+dpkg (1.21.7+nmu1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * dpkg.postinst: Remove warning about merged-/usr. Closes: #1008489
+
+ -- Ansgar Sat, 09 Apr 2022 11:00:38 +0200
+
dpkg (1.21.7) unstable; urgency=medium
- The “Social Contract §3: We will not hide problems”
diff --git a/debian/dpkg.postinst b/debian/dpkg.postinst
index 83a4873..5aee110 100644
--- a/debian/dpkg.postinst
+++ b/debian/dpkg.postinst
@@ -9,42 +9,6 @@ PROGNAME=dpkg
setup_colors
-get_vendor()
-{
- local origin="$DPKG_ROOT/etc/dpkg/origins/default"
- local vendor
-
- if [ -e "$origin" ]; then
-vendor=$(sed -ne 's/^Vendor: *\([^ ]\+\) */\1/p' "$origin" | tr '[A-Z]' '[a-z]')
- fi
-
- echo "${vendor:-default}"
-}
-
-check_merged_usr_via_aliased_dirs()
-{
- local vendor
-
- vendor=$(get_vendor)
-
- # In Debian some people have gotten so offended by the following _warning_
- # that they have resorted to bullying and abuse. Life's too short, sorry.
- if [ "$vendor" = "debian" ]; then
-return
- fi
-
- for d in /bin /sbin /lib /lib32 /libo32 /libx32 /lib64; do
-linkname="$(readlink $DPKG_ROOT$d || true)"
-if [ "$linkname" = "usr$d" ] || [ "$linkname" = "/usr$d" ]; then
- warning "This system uses merged-usr-via-aliased-dirs, going behind dpkg's"
- warning "back, breaking its core assumptions. This can cause silent file"
- warning "overwrites and disappearances, and its general tools misbehavior."
- warning "See ."
- break
-fi
- done
-}
-
# Version 1.21.0 had bogus handling of DPKG_ADMINDIR in update-alternatives,
# and misplaced them, fix them up.
fixup_misplaced_alternatives()
@@ -93,8 +57,6 @@ fixup_misplaced_alternatives()
case "$1" in
configure)
fixup_misplaced_alternatives
-
- check_merged_usr_via_aliased_dirs
;;
abort-upgrade|abort-deconfigure|abort-remove)
;;
--
2.35.1
