Devuan bug report logs - #813
netcat-traditional: Debian Bug#1056980: netcat-traditional: upgrade to 1.10-48 fails (postinst

Full log

🔗 View this message in rfc822 format

X-Loop: owner@bugs.devuan.org
Subject: bug#813: Bug#1056980: Reopen 1056980
Reply-To: Helmut Grohne <helmut@subdivi.de>, 813@bugs.devuan.org
Resent-From: Helmut Grohne <helmut@subdivi.de>
Resent-To: devuan-bugs@lists.dyne.org
Resent-CC: Devuan Developers <devuan-dev@lists.dyne.org>
X-Loop: owner@bugs.devuan.org
Resent-Date: Fri, 08 Dec 2023 20:44:01 +0000
Resent-Message-ID: <handler.813.B813.170206821513352@bugs.devuan.org>
Resent-Sender: owner@bugs.devuan.org
X-Devuan-PR-Message: followup 813
X-Devuan-PR-Package: devuan-project
X-Devuan-PR-Keywords: 
References: <16c3e58c-b503-4d0e-912f-3648e4c67234@stinpriza.org> <eadb844143c7de3dfe6f4cd7058bd88f85a71ac5.camel@gmail.com> <170169630315.18258.8836205405161711723.reportbug@localhost>
Received: via spool by 813-submit@bugs.devuan.org id=B813.170206821513352
          (code B ref 813); Fri, 08 Dec 2023 20:44:01 +0000
Received: (at 813) by bugs.devuan.org; 8 Dec 2023 20:43:35 +0000
Delivered-To: bugs@devuan.org
Received: from email.devuan.org [2a01:4f8:a0:3284::74ca:8ad2]
	by doc.devuan.org with IMAP (fetchmail-6.4.16)
	for <debbugs@localhost> (single-drop); Fri, 08 Dec 2023 20:43:35 +0000 (UTC)
Received: from email.devuan.org
	by email.devuan.org with LMTP
	id TQCWIrN/c2VPEAAAmSBk0A
	(envelope-from <helmut@subdivi.de>)
	for <bugs@devuan.org>; Fri, 08 Dec 2023 20:42:27 +0000
Received: by email.devuan.org (Postfix, from userid 109)
	id 81E5B647; Fri,  8 Dec 2023 20:42:27 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on email.devuan.org
X-Spam-Level: 
X-Spam-Status: No, score=-5.0 required=5.0 tests=RCVD_IN_DNSWL_HI,SPF_NONE
	autolearn=ham autolearn_force=no version=3.4.6
Received-SPF: None (mailfrom) identity=mailfrom; client-ip=136.243.71.142; helo=isilmar-4.linta.de; envelope-from=helmut@subdivi.de; receiver=<UNKNOWN> 
Received: from isilmar-4.linta.de (isilmar-4.linta.de [136.243.71.142])
	by email.devuan.org (Postfix) with ESMTPS id 5B0DD27
	for <813@bugs.devuan.org>; Fri,  8 Dec 2023 20:42:26 +0000 (UTC)
Received: from isilmar-4.linta.de (isilmar.linta [10.0.0.1])
	by isilmar-4.linta.de (Postfix) with ESMTP id C3EFD200230;
	Fri,  8 Dec 2023 20:42:24 +0000 (UTC)
Date: Fri, 8 Dec 2023 21:42:05 +0100
From: Helmut Grohne <helmut@subdivi.de>
To: svante.signell@gmail.com, 1056980-done@bugs.debian.org
Cc: 813@bugs.devuan.org
Message-ID: <20231208204205.GA20144@subdivi.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <eadb844143c7de3dfe6f4cd7058bd88f85a71ac5.camel@gmail.com>

Hi Svante,

On Fri, Dec 08, 2023 at 04:15:01PM +0100, Svante Signell wrote:
> Reopening this bug due to a deliberate attempt to fool the users: Either you move binaries _and_ configuration files 
> to /usr/bin or explicitely depend on usrmerge. And closing this bug as wontfix is not nice.

This sounds simple to you, but it really is not. Effectively you are
asking us to do one of three things:

a. Not move the binaries
b. Move the binaries and alternatives
c. Depends on usrmerge

Let me decline all of them with reason.

a. Doing this would imply a permanent symlink vs directory conflict for
   /bin and also causes us to continue experiencing aliasing-related
   issues. We've ruled this out early on.

b. Moving alternatives is difficult. It actually is on two levels. For
   one thing, the alternative has a name and a location. If you move the
   location of an alternative, all providers must move it at the same
   time or bad things will happen. On a technical level, this is very
   difficult to achieve and hence we recommend not doing it. Then you
   can consider moving an actual provider. Unfortunately, that path has
   become API of the alternatives system, so in moving it we break
   integrations (ansible/chef/propellor/puppet/etc). In all of this
   migration, we must ensure that user configuration is not lost. So
   we've opted to not solve this for now. I invite you to present a
   solution, but the solution you gave falls short on a number of
   problems mentioned here. So arguably wontfix is maybe too strong, but
   in effect that doesn't change what we'll be doing here: keeping
   alternatives aliased (at least for now).

c. usrmerge already is essential since bookworm. Therefore, there is an
   implicit dependency on it already and spelling out such a dependency
   is redundant. We actually want to get rid of the package before too
   long, so adding dependencies on it would make that harder to do.

> I've modified netcat-traditional.postinst on both usrmerged and non-usrmerged systems without problems. So your second comment b) in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056980#15
> is definitely false:
> 
> From: Chris Hofstaedtler <[zeha@debian.org](mailto:zeha@debian.org)>  
> ...
> No, changing the update-alternatives call is  
> a) not necessary on /usr-merged systems,  
> b) will break on these.
> 
> No the system did not break!

Yeah, I understand it does not break your things, but I identified that
it does break other things.

That said, it's actually great to have people look into options for
moving alternatives. Keeping them aliased definitely causes unfortunate
surprises to end users, so being able to move them eventually would be
cool really. We just haven't found a good way to do it yet. What we lack
here is people coming up with a good solution and if you want to be the
one, then yes, go for it! Though please don't upload it right away and
rather discuss your solution about the alternatives preferably on
debian-devel@lists.debian.org first. Let me caution though that I very
much doubt there to be a solution that does not involve changing dpkg,
because not having a backwards-compatibility mechanism would annoy a lot
of devops people.

> Yes, I have read [https://wiki.debian.org/UsrMerge](https://wiki.debian.org/UsrMerge)  
> 
> And found:  
> ! Please suspend further moves temporarily. The effects of moves cause more problems than anticipated 
> people are working to understand and solve them. Exceptions: Continue to perform moves that fix RC bugs
> (e.g. dh_installsystemd or systemd.pc issues) and DEP17P7 mitigations for udev rules.
> 
> And:
> Do not update calls to update-alternatives:
> - Even if you move e.g. /bin/more to /usr/bin/more, do not change the location used in the 
>   update-alternatives invocation.
> - If you add new alternatives, install them to /usr if possible. 
> 
> And:
> P4: Even when changing all aliased paths from / to /usr, you must not change the paths passed to update-alternatives
> invocations that already existed in bookworm. The current plan is to keep existing alternatives aliased as a legacy
> forever and add new alternatives without aliasing. 
> 
> Who wrote this? The question is why?? All changes to packages moving files to /usr should also move _all_ 
> corresponding configuration files to, or add an explicit dependency on usrmerge!

I wrote this! I hope the reasoning is answered given the above now.

In the end though, what I wrote doesn't change much here and I am
basically confirming Christian and Luca.  netcat-traditional cannot do
anything about this at this time. This bug is not actionable
unfortunately. I am thus closing it. Please don't continue on the netcat
side. It's a distro-wide problem and should go to d-devel@l.d.o.

Thanks for your understanding

Helmut

Send a report that this bug log contains spam.