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

Package: devuan-project; Maintainer for devuan-project is Devuan Developers <devuan-dev@lists.dyne.org>;

Affects: sed, firmware-realtek, netcat-traditional, linux-headers-6.6.8-amd64, kmod, initramfs-tools-core

Reported by: Arthur Marsh <arthur.marsh@internode.on.net>

Date: Mon, 4 Dec 2023 13:28:01 UTC

Severity: grave

Merged with 812, 821, 823, 826, 827, 828

Done: Mark Hindley <mark@hindley.org.uk>

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to devuan-bugs@lists.dyne.org, devuan-dev@lists.dyne.org:
bug#813; Package netcat-traditional. (Mon, 04 Dec 2023 13:28:01 GMT) (full text, mbox, link).


Acknowledgement sent to Arthur Marsh <arthur.marsh@internode.on.net>:
New bug report received and forwarded. Copy sent to devuan-dev@lists.dyne.org. (Mon, 04 Dec 2023 13:28:02 GMT) (full text, mbox, link).


Message #5 received at submit@bugs.devuan.org (full text, mbox, reply):

From: Arthur Marsh <arthur.marsh@internode.on.net>
To: Devuan Bug Tracking System <submit@bugs.devuan.org>
Subject: netcat-traditional: Debian Bug#1056980: netcat-traditional: upgrade to 1.10-48 fails (postinst
Date: Mon, 04 Dec 2023 23:55:03 +1030
Package: netcat-traditional
Version: 1.10-48
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Attempting to upgrade netcat-traditional 1.10-48 on unstable in Devuan.

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

Found Debian Bug#1056980 marked as wontfix.

   * What was the outcome of this action?

Frustration.

   * What outcome did you expect instead?

A working transition.

*** End of the template - remove these template lines ***


-- System Information:
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 6 (excalibur/ceres)
Release:	6
Codename:	excalibur ceres
Architecture: x86_64

Kernel: Linux 6.7.0-rc3+ (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages netcat-traditional depends on:
ii  libc6  2.38-3

netcat-traditional recommends no packages.

netcat-traditional suggests no packages.

-- no debconf information

Information forwarded to devuan-bugs@lists.dyne.org, devuan-dev@lists.dyne.org:
bug#813; Package netcat-traditional. (Mon, 04 Dec 2023 13:36:02 GMT) (full text, mbox, link).


Acknowledgement sent to B Stack <bgstack15@gmail.com>:
Extra info received and forwarded to list. Copy sent to devuan-dev@lists.dyne.org. (Mon, 04 Dec 2023 13:36:02 GMT) (full text, mbox, link).


Message #10 received at 813@bugs.devuan.org (full text, mbox, reply):

From: B Stack <bgstack15@gmail.com>
To: Arthur Marsh <arthur.marsh@internode.on.net>, 813@bugs.devuan.org, devuan developers internal list <devuan-dev@lists.dyne.org>
Cc: Devuan Bug Tracking System <submit@bugs.devuan.org>
Subject: Re: [devuan-dev] bug#813: netcat-traditional: Debian Bug#1056980: netcat-traditional: upgrade to 1.10-48 fails (postinst
Date: Mon, 4 Dec 2023 08:33:30 -0500
Of course this is related to usrmerge in our upstream distro, and is
solved once you `apt-get install usrmerge` which was blocked for me
until I also ran:

    sudo rm -f /lib/udev/rules.d/99-libsane1.rules
/lib/udev/rules.d/60-libsane1.rules /lib/udev/hwdb.d/20-sane.hwdb

For some reason. Now of course these steps don't actually fix
netcat-traditional itself for a non-merged system, but it does allow
the package to finish installing.

--
B. Stack

Information forwarded to devuan-bugs@lists.dyne.org, devuan-dev@lists.dyne.org:
bug#813; Package netcat-traditional. (Mon, 04 Dec 2023 14:30:01 GMT) (full text, mbox, link).


Acknowledgement sent to svante.signell@gmail.com:
Extra info received and forwarded to list. Copy sent to devuan-dev@lists.dyne.org. (Mon, 04 Dec 2023 14:30:04 GMT) (full text, mbox, link).


Message #15 received at 813@bugs.devuan.org (full text, mbox, reply):

From: Svante Signell <svante.signell@gmail.com>
To: 813@bugs.devuan.org
Subject: Fwd: Re: [devuan-dev] bug#813: netcat-traditional: Debian Bug#1056980: netcat-traditional: upgrade to 1.10-48 fails (postinst
Date: Mon, 04 Dec 2023 15:28:48 +0100
[Message part 1 (text/plain, inline)]

[Message part 2 (message/rfc822, inline)]
From: Svante Signell <svante.signell@gmail.com>
To: devuan-dev@lists.dyne.org
Subject: Re: [devuan-dev] bug#813: netcat-traditional: Debian Bug#1056980: netcat-traditional: upgrade to 1.10-48 fails (postinst
Date: Mon, 04 Dec 2023 15:26:47 +0100
On Mon, 2023-12-04 at 08:33 -0500, B Stack wrote:
> Of course this is related to usrmerge in our upstream distro, and is
> solved once you `apt-get install usrmerge` which was blocked for me
> until I also ran:
> 
>     sudo rm -f /lib/udev/rules.d/99-libsane1.rules
> /lib/udev/rules.d/60-libsane1.rules /lib/udev/hwdb.d/20-sane.hwdb
> 
> For some reason. Now of course these steps don't actually fix
> netcat-traditional itself for a non-merged system, but it does allow
> the package to finish installing.

You should not be forced to install usrmerge in a Devuan system. That package
will be forked by Devuan.

FYI: You can always revert the usrmerge installation with dpkg-fsys-usrunmess!


Information forwarded to devuan-bugs@lists.dyne.org, devuan-dev@lists.dyne.org:
bug#813; Package netcat-traditional. (Tue, 05 Dec 2023 12:56:01 GMT) (full text, mbox, link).


Message #18 received at 813@bugs.devuan.org (full text, mbox, reply):

From: Mark Hindley <mark@hindley.org.uk>
To: svante.signell@gmail.com, 813@bugs.devuan.org, Arthur Marsh <arthur.marsh@internode.on.net>
Subject: Re: bug#813: Fwd: Re: [devuan-dev] bug#813: netcat-traditional: Debian Bug#1056980: netcat-traditional: upgrade to 1.10-48 fails (postinst
Date: Tue, 5 Dec 2023 12:53:31 +0000
Control: reassign -1 devuan-project
Control: forcemerge 810 -1
Control: affects -1 netcat-traditional

On Mon, Dec 04, 2023 at 03:28:48PM +0100, Svante Signell wrote:
> You should not be forced to install usrmerge in a Devuan system. That package
> will be forked by Devuan.

Svante,

I am not sure either of these assertions is agreed Devuan policy.

Arthur,

Installing usrmerge should fix this which Devuan has inherited (however
unwelcome that may be) from Debian. See[1] for a fuller explanation.

Reassigning and merging.

Mark

[1]  https://bugs.devuan.org/cgi/bugreport.cgi?bug=810#15


bug reassigned from package 'netcat-traditional' to 'devuan-project'. Request was from Mark Hindley <mark@hindley.org.uk> to 813-submit@bugs.devuan.org. (Tue, 05 Dec 2023 12:56:02 GMT) (full text, mbox, link).


No longer marked as found in versions 1.10-48. Request was from Mark Hindley <mark@hindley.org.uk> to 813-submit@bugs.devuan.org. (Tue, 05 Dec 2023 12:56:02 GMT) (full text, mbox, link).


Severity set to 'grave' from 'normal' Request was from Mark Hindley <mark@hindley.org.uk> to 813-submit@bugs.devuan.org. (Tue, 05 Dec 2023 12:56:02 GMT) (full text, mbox, link).


Added indication that 813 affects wpasupplicant Request was from Mark Hindley <mark@hindley.org.uk> to 813-submit@bugs.devuan.org. (Tue, 05 Dec 2023 12:56:02 GMT) (full text, mbox, link).


Merged 810 813 Request was from Mark Hindley <mark@hindley.org.uk> to 813-submit@bugs.devuan.org. (Tue, 05 Dec 2023 12:56:02 GMT) (full text, mbox, link).


Added indication that 813 affects netcat-traditional Request was from Mark Hindley <mark@hindley.org.uk> to 813-submit@bugs.devuan.org. (Tue, 05 Dec 2023 12:56:02 GMT) (full text, mbox, link).


Merged 810 812 813 Request was from Mark Hindley <mark@hindley.org.uk> to 812-submit@bugs.devuan.org. (Tue, 05 Dec 2023 13:02:02 GMT) (full text, mbox, link).


Added indication that 813 affects firmware-realtek Request was from Mark Hindley <mark@hindley.org.uk> to 812-submit@bugs.devuan.org. (Tue, 05 Dec 2023 13:02:02 GMT) (full text, mbox, link).


Information forwarded to devuan-bugs@lists.dyne.org, Devuan Developers <devuan-dev@lists.dyne.org>:
bug#813; Package devuan-project. (Tue, 05 Dec 2023 15:32:01 GMT) (full text, mbox, link).


Acknowledgement sent to svante.signell@gmail.com:
Extra info received and forwarded to list. Copy sent to Devuan Developers <devuan-dev@lists.dyne.org>. (Tue, 05 Dec 2023 15:32:03 GMT) (full text, mbox, link).


Message #39 received at 813@bugs.devuan.org (full text, mbox, reply):

From: Svante Signell <svante.signell@gmail.com>
To: Mark Hindley <mark@hindley.org.uk>, 813@bugs.devuan.org, Arthur Marsh <arthur.marsh@internode.on.net>
Cc: Devuan dng ml <dng@lists.dyne.org>, Klaus Ethgen <Klaus@ethgen.ch>
Subject: Debian maintainers deliberately breaks unmerged systems: Was: Re: bug#813:...
Date: Tue, 05 Dec 2023 16:31:39 +0100
On Tue, 2023-12-05 at 12:53 +0000, Mark Hindley wrote:
> Control: reassign -1 devuan-project
> Control: forcemerge 810 -1
> Control: affects -1 netcat-traditional
> 
> On Mon, Dec 04, 2023 at 03:28:48PM +0100, Svante Signell wrote:
> > You should not be forced to install usrmerge in a Devuan system. That
> > package will be forked by Devuan.
> 
> Svante,
> 
> I am not sure either of these assertions is agreed Devuan policy.
> 

Maybe I should have written "will (probably) be forked by Devuan"
Nevertheless, reassigning the bugs 810, 812 and 813 to devuan-project means
what? Do we continue the discussion or is the project decision that all packages
coming from Debian showing this foul play will silently be hidden by a
recommendation to install usrmerge on Devuan/Ceres/Excalibur?

In my opinion this is to give up on their dictatorship! See further comments
below!

> Arthur,
> 
> Installing usrmerge should fix this which Devuan has inherited (however
> unwelcome that may be) from Debian. See[1] for a fuller explanation.
> 
> Reassigning and merging.
> 
> Mark
> 
> [1]  https://bugs.devuan.org/cgi/bugreport.cgi?bug=810#15
> 
Quoting from bug=810#26 and #31:

bug=810#26
> > Believe me that I think this Debian exercise is a waste of time, driven by
> > systemd dogma. However, for Devaun to attempt to fork every Debian package
> would
> > just waste even more time. I do not believe this to be worthwhile.
> 
> Yes, that is a disaster... My hope was, that at least Devuan is able to
> mitigate it and keeping up the good quality that Debian was before
> systemd.
> 
> However, I also see that there seems to be only few persons behind to do
> the work.
> 
> > I imagine you will suggest forking wpasupplicant, however that one package
> is not the fundamental issue here. Most, maybe all Debian packages are going
> to have their binaries moved in the next few months and for Devuan to resist
> by forking would be unsustainable.
> 
> It might be needed to fork the distribution completely. Well, at least
> with the main packages. There could still be some compatibility left for
> contrib and non-free. I mean, debian was small too in the past. Why not
> start from scratch? (You even don't need to start without anything)
> Maybe it is time for a cut.
> 
> I try to fix packages myself as I did for openssh[0], pcre2[1] and since
> today pcsc-lite[2]. And I have now a massive ansible role to fix all the
> debian bugs as well as nagios check for broken libraries that should be
> in /lib.
> 
> > I believe you have two options (I fear you will find neither palatable, for
> > which I apologise):-
> > 
> >  - Install Daedalus and do not upgrade beyond that.
> > 
> >  - Install the usrmerge package.
> 
> The last one will never be an option for me! Before that I would destroy
> all my computers first or migrate to windows! (What, if you know me, I
> would never do.)
> 
> The first would be a solution only up to when the support for that
> distribution ends.
> 

bug=810#31
> > 
> > > > Believe me that I think this Debian exercise is a waste of time,
> > > > driven by systemd dogma. However, for Devaun to attempt to fork
> > > > every Debian package would just waste even more time. I do not
> > > > believe this to be worthwhile.
> > > 
> > 
> > It seems to be around 40 packages according to Lorenzo, not too many. I
> > volunteer to adopt 5-10 of them. Just let me know.
> > 
> > Yes, that is a disaster... My hope was, that at least Devuan is able
> > to mitigate it and keeping up the good quality that Debian was before
> > systemd.
> > 
> > However, I also see that there seems to be only few persons behind to
> > do the work.
> 
> Count me in! If we won't resist Debian brainless merged /usr, I'll
> have no motivation to create a Devuan Port of GNU/Hurd.

> > It might be needed to fork the distribution completely. Well, at
> > least with the main packages. There could still be some compatibility
> > left for contrib and non-free. I mean, debian was small too in the
> > past. Why not start from scratch? (You even don't need to start
> > without anything) Maybe it is time for a cut.
> > 
> 
> Yes, please!
> 
> I recently moverd all my desktops and laptops to Devuan/Daedalus, and
> would prefer to continue with Devuan!
> 
> Otherwise, I would switch to Guix if Devuan no longer is an
> alternative. Never again adopt Debian/RedHat madness!

Information forwarded to devuan-bugs@lists.dyne.org, Devuan Developers <devuan-dev@lists.dyne.org>:
bug#813; Package devuan-project. (Tue, 05 Dec 2023 16:08:01 GMT) (full text, mbox, link).


Acknowledgement sent to Mark Hindley <mark@hindley.org.uk>:
Extra info received and forwarded to list. Copy sent to Devuan Developers <devuan-dev@lists.dyne.org>. (Tue, 05 Dec 2023 16:08:02 GMT) (full text, mbox, link).


Message #44 received at 813@bugs.devuan.org (full text, mbox, reply):

From: Mark Hindley <mark@hindley.org.uk>
To: Svante Signell <svante.signell@gmail.com>
Cc: 813@bugs.devuan.org, Arthur Marsh <arthur.marsh@internode.on.net>, Devuan dng ml <dng@lists.dyne.org>, Klaus Ethgen <Klaus@ethgen.ch>
Subject: Re: Debian maintainers deliberately breaks unmerged systems: Was: Re: bug#813:...
Date: Tue, 5 Dec 2023 16:06:56 +0000
On Tue, Dec 05, 2023 at 04:31:39PM +0100, Svante Signell wrote:
> Maybe I should have written "will (probably) be forked by Devuan"
> Nevertheless, reassigning the bugs 810, 812 and 813 to devuan-project means
> what?

It means that, depspite the specifc package issues, we have to decide how to
handle it for the whole project. It will not scale to do this on a per-package
basis.

> Do we continue the discussion or is the project decision that all packages
> coming from Debian showing this foul play will silently be hidden by a
> recommendation to install usrmerge on Devuan/Ceres/Excalibur?

I think that was the reluctant conclusion we came to last time it was
discussed. But I am prepared to be corrected.

Mark

Message #45 received at 810-done@bugs.devuan.org (full text, mbox, reply):

From: Svante Signell <svante.signell@gmail.com>
To: 810@bugs.devuan.org
Cc: 810-done@bugs.devuan.org
Subject: Bug #810 on wpasupplicant: Fixed, closing
Date: Wed, 06 Dec 2023 17:44:29 +0100
Hello,

As you might have found out this bug has been resolved by 2:2.10-18, fixed by
patches for bug #1056976 by Guillem Jover.

Thanks, closing!

Disconnected #810 from all other report(s). Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 06 Dec 2023 17:14:01 GMT) (full text, mbox, link).


Bug reopened Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 06 Dec 2023 17:20:01 GMT) (full text, mbox, link).


Removed indication that 813 affects wpasupplicant Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 06 Dec 2023 17:34:01 GMT) (full text, mbox, link).


Information forwarded to devuan-bugs@lists.dyne.org, Devuan Developers <devuan-dev@lists.dyne.org>:
bug#813; Package devuan-project. (Fri, 08 Dec 2023 15:16:01 GMT) (full text, mbox, link).


Acknowledgement sent to svante.signell@gmail.com:
Extra info received and forwarded to list. Copy sent to Devuan Developers <devuan-dev@lists.dyne.org>. (Fri, 08 Dec 2023 15:16:02 GMT) (full text, mbox, link).


Message #56 received at 813@bugs.devuan.org (full text, mbox, reply):

From: Svante Signell <svante.signell@gmail.com>
To: 1056980@bugs.debian.org
Cc: Debian Control Server <control@bugs.debian.org>, 813@bugs.devuan.org
Subject: Reopen 1056980
Date: Fri, 08 Dec 2023 16:15:01 +0100
[Message part 1 (text/markdown, inline)]
reopen 1056980  
severity 1056980 serious  
tags 1056980 patch  
thanks

Hello,

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.

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!

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!

Thanks!



Information forwarded to devuan-bugs@lists.dyne.org, Devuan Developers <devuan-dev@lists.dyne.org>:
bug#813; Package devuan-project. (Fri, 08 Dec 2023 15:38:01 GMT) (full text, mbox, link).


Acknowledgement sent to svante.signell@gmail.com:
Extra info received and forwarded to list. Copy sent to Devuan Developers <devuan-dev@lists.dyne.org>. (Fri, 08 Dec 2023 15:38:02 GMT) (full text, mbox, link).


Message #61 received at 813@bugs.devuan.org (full text, mbox, reply):

From: Svante Signell <svante.signell@gmail.com>
To: 813@bugs.devuan.org, devuan developers internal list <devuan-dev@lists.dyne.org>, 1056980@bugs.debian.org
Cc: Debian Control Server <control@bugs.debian.org>
Subject: Re: [devuan-dev] bug#813: Reopen 1056980
Date: Fri, 08 Dec 2023 16:37:09 +0100
[Message part 1 (text/plain, inline)]
On Fri, 2023-12-08 at 16:15 +0100, Svante Signell wrote:
> reopen 1056980
> severity 1056980 serious
> tags 1056980 patch
> thanks

Sorry, forgot the patch!

[debian_netcat-traditional.postinst.patch (text/x-patch, attachment)]

Information forwarded to devuan-bugs@lists.dyne.org, Devuan Developers <devuan-dev@lists.dyne.org>:
bug#813; Package devuan-project. (Fri, 08 Dec 2023 20:44:01 GMT) (full text, mbox, link).


Acknowledgement sent to Helmut Grohne <helmut@subdivi.de>:
Extra info received and forwarded to list. Copy sent to Devuan Developers <devuan-dev@lists.dyne.org>. (Fri, 08 Dec 2023 20:44:02 GMT) (full text, mbox, link).


Message #66 received at 813@bugs.devuan.org (full text, mbox, reply):

From: Helmut Grohne <helmut@subdivi.de>
To: svante.signell@gmail.com, 1056980-done@bugs.debian.org
Cc: 813@bugs.devuan.org
Subject: Re: Bug#1056980: Reopen 1056980
Date: Fri, 8 Dec 2023 21:42:05 +0100
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


Removed indication that 813 affects firmware-realtek and netcat-traditional Added indication that 813 affects netcat-traditional,firmware-realtek Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:50:02 GMT) (full text, mbox, link).


Merged 812 813 821 Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:50:02 GMT) (full text, mbox, link).


Added indication that 813 affects linux-headers-6.6.8-amd64 Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:50:02 GMT) (full text, mbox, link).


Removed indication that 813 affects netcat-traditional, firmware-realtek, and linux-headers-6.6.8-amd64 Added indication that 813 affects linux-headers-6.6.8-amd64,netcat-traditional,firmware-realtek Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:52:02 GMT) (full text, mbox, link).


Merged 812 813 821 823 Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:52:02 GMT) (full text, mbox, link).


Added indication that 813 affects sed Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:52:02 GMT) (full text, mbox, link).


Removed indication that 813 affects sed, firmware-realtek, netcat-traditional, and linux-headers-6.6.8-amd64 Added indication that 813 affects netcat-traditional,linux-headers-6.6.8-amd64,firmware-realtek,sed Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:54:01 GMT) (full text, mbox, link).


Merged 812 813 821 823 827 Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:54:01 GMT) (full text, mbox, link).


Added indication that 813 affects initramfs-tools-core Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:54:02 GMT) (full text, mbox, link).


Removed indication that 813 affects sed, firmware-realtek, linux-headers-6.6.8-amd64, netcat-traditional, and initramfs-tools-core Added indication that 813 affects firmware-realtek,initramfs-tools-core,netcat-traditional,linux-headers-6.6.8-amd64,sed Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:54:02 GMT) (full text, mbox, link).


Merged 812 813 821 823 826 827 Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:54:03 GMT) (full text, mbox, link).


Added indication that 813 affects kmod Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:54:03 GMT) (full text, mbox, link).


Removed indication that 813 affects firmware-realtek, linux-headers-6.6.8-amd64, sed, initramfs-tools-core, netcat-traditional, and kmod Added indication that 813 affects firmware-realtek,linux-headers-6.6.8-amd64,kmod,sed,initramfs-tools-core,netcat-traditional Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:56:02 GMT) (full text, mbox, link).


Merged 812 813 821 823 826 827 828 Request was from Mark Hindley <mark@hindley.org.uk> to control@bugs.devuan.org. (Wed, 20 Mar 2024 11:56:02 GMT) (full text, mbox, link).


Message #95 received at 812-done@bugs.devuan.org (full text, mbox, reply):

From: Mark Hindley <mark@hindley.org.uk>
To: 812-done@bugs.devuan.org
Subject: Re: bug#812: Devuan project: merged-usr
Date: Wed, 20 Mar 2024 12:06:27 +0000
Merged /usr is now enforced by base-files 13devuan4 and handled by debootstrap
1.0.134devuan2. Both of these versions are present in ceres and excalibur:

 base-files  | 13devuan4      | excalibur  | source, all
 base-files  | 13devuan4      | unstable   | source, all
 debootstrap | 1.0.134devuan2 | excalibur  | source, all
 debootstrap | 1.0.134devuan2 | unstable   | source, all

Golinux also posted an announcement[1] on the forum.

Therefore I am closing these reports as fixed.

Mark

[1]  https://dev1galaxy.org/viewtopic.php?id=6435      



Send a report that this bug log contains spam.


Devuan BTS -- Powered by Debian bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.

Devuan Bugs Owner <owner@bugs.devuan.org>.
Last modified: Fri May 24 08:08:51 2024;