Hi Thorsten,
On Tue, Aug 06, 2024 at 02:18:17PM +0000, Thorsten Glaser wrote:
> we have exchanged numerous eMails, and you’ve not disagreed with
> the last points you raised. I did get a disagreement from guillem
> about omitting the top-level directory (which was only a workaround
> for the “dpkg-deb -x mksh.deb / will break a /usr-merged system”
> thing you said.
I saw no point in disagreeing any further as I had given my arguments.
We still have wide consensus in Debian on how to finish this transition
and that is why I reopened the bugs.
I would like to take the opportunity make you aware of a Debian policy
change #1074014 about merged-/usr. I mentioned your approach in mksh and
pax and the consensus among discussion participants was that policy
should not allow for such interpretation. We have six seconds on the
following diff now:
- To support merged-/usr systems, packages must not install files in both
- /path and /usr/path. For example, a package must not install both
- /bin/example and /usr/bin/example.
+ Since base-files implements mandatory merged-/usr by installing the
+ aliasing symbolic links, other packages must not install files into
+ aliased paths such as /bin, /lib, /lib* or /sbin. The package manager is
+ not prepared to deal with such aliasing and in prohibiting the
+ installation into aliased locations, we avoid triggering undefined
+ behaviour. Conversely, packages may assume that /bin, /lib and /sbin are
+ symlinks at all times and that their files below /usr/bin, /usr/lib and
+ /usr/sbin are also accessible via their aliased locations.
I expect this policy change to come into effect before trixie is
released and the current mksh and pax will be violating said policy.
There also is a proposal of adding a check to dak. If that were to be
implemented, builds of your packages would be rejected by dak and you
would be unable to update your package.
> There are two places to address:
>
> 1. the /bin symlink
>
> The implicit Pre-Depends on the Essential set being unpacked,
> where base-files contains the /bin symlink, is sufficient to
> avoid /bin ending up as a directory. No action needs to be
> taken in the packages that are not part of the (Pseudo‑)Essential
> set.
This relies on undefined behaviour in dpkg. Guillem is working on
improving metadata tracking and accurately tracking metadata will make
this break. It is not enough to rely on the implicit essential
dependency.
> 2. the dpkg-deb -x issue
>
> Since guillem has rejected the possible workaround suggestion,
> he, as dpkg maintainer, can fix this in dpkg-deb itself.
We have a relatively wide consensus on how to work around this problem.
It does not help if part of the project fixes it in another way.
> Au contraire, moving the files WILL break users’ systems, as
> having /bin/sh be a symlink to lksh is a supported configuration,
> and I am a̲b̲s̲o̲̲l̲u̲t̲e̲l̲̲y̲ ̲N̲O̲T̲ taking a possible convoluted thing to
> work around this. mksh is continuously backported (not in bpo)
> as well, I’m totally not going to break things.
I recommend using dh_movetousr or dh-sequence-movetousr in order to
facilitate backports. If you want to backport beyond bookworm, consider
the following rune:
execute_before_dh_installdeb:
if command -v dh_movetousr >/dev/null; then dh_movetousr; fi
In versions before bookworm, dh_movetousr does not exist and thus is
skipped. debhelper in bookworm-backports includes dh_movetousr and it
does nothing there. Only for trixie and later it will actually move
files.
I expect that the use of dh_movetousr alleviates your concern about
breaking users. If not, please elaborate.
I kindly request that you reopen these bugs for tracking purpose. I
believe that I have presented sufficient evidence that something needs
to be done about them even though we disagree about what that something
is.
Helmut
