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@???](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@??? 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@???.

Thanks for your understanding

Helmut