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

Reply or subscribe to this bug.

Toggle useless messages

---

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

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

---

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

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

---

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

[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!

---

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

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

---

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

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!

---

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

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):

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!

---

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

[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!

---

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

[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)]

---

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

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

---

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

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.

---