Bug#1074014: encode mandatory merged-/usr into policy

[Sean Whitton]

Hello,

On Thu 25 Jul 2024 at 03:12pm +02, Helmut Grohne wrote:

> Can a policy editor follow up with instructions on where we are (from a
> policy procedures point of view) and what needs to be done to move this
> proposal forward?

I'm focused on tag2upload right now.  If Russ doesn't get to this soon,
please ping again.

-- 
Sean Whitton

Bug#1074014: encode mandatory merged-/usr into policy

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:

Helmut> seconds from * Chris Hofstaedtler * Holger Levsen * Jochen
Helmut> Sprickerhof * Luca Boccassi * Michael Biebl

It was my intent to second as well.
I like Russ's proposal too.



signature.asc
Description: PGP signature

Bug#1074014: encode mandatory merged-/usr into policy

[Helmut Grohne]

Hi,

On Fri, Jun 21, 2024 at 08:27:57PM +0200, Helmut Grohne wrote:
> given the progress we have made with /usr-move and DEP17, I think it is
> time to consider encoding the changes into policy. As of this writing,
> there are 216 source packages in unstable that still install into
> aliased locations and their number has been dropping since a while. All
> but very few packages have bug reports of important severity and will
> have their severity upgraded to serious on August 6th.

118 source packages as of this writing.

I think we have quite positive feedback from both policy editors and
others. We have a proposed wording and we have seconds from
 * Chris Hofstaedtler
 * Holger Levsen
 * Jochen Sprickerhof
 * Luca Boccassi
 * Michael Biebl

I am happy to move forward with or without Russ' proposed addition
however you see fit and generally think it is good advice:

| Since paths either with or without /usr are supported on Debian
| systems, maintainers of non-native packages are encouraged to follow
| the same conventions as the upstream package when referencing absolute
| paths.  There is no need to change upstream code from, for example,
| /bin to /usr/bin (or from /usr/bin to /bin) when packaging for Debian.

Can a policy editor follow up with instructions on where we are (from a
policy procedures point of view) and what needs to be done to move this
proposal forward?

Thanks

Helmut

Bug#1074014: encode mandatory merged-/usr into policy

[Jochen Sprickerhof]

* Helmut Grohne  [2024-06-21 20:27]:

For these reasons, I propose changing section 10.1 and encoding the
avoidance of symlink vs directory conflicts into policy. To get a
discussion going, I suggest the following update.

- 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.


seconded.


Questions:
1. Do you agree that policy should be changed?


yes.


If yes:

2. Do you agree that policy should prohibit installing into aliased
   paths?


yes.


3. Do you agree that the current progress is sufficient for changing
   policy?


yes.


4. Do you agree with the proposed wording?


yes.


5. Given earlier disagreement on this matter, should we discuss this
   matter in a wider setting such as d-devel?


no.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#1074014: encode mandatory merged-/usr into policy

[Michael Biebl]

On Fri, 21 Jun 2024 20:27:56 +0200 Helmut Grohne  wrote:

Package: debian-policy
Version: 4.7.0.0
X-Debbugs-Cc: bl...@debian.org,m...@debian.org,mbi...@debian.org,z...@debian.org

Hi,

given the progress we have made with /usr-move and DEP17, I think it is
time to consider encoding the changes into policy. As of this writing,
there are 216 source packages in unstable that still install into
aliased locations and their number has been dropping since a while. All
but very few packages have bug reports of important severity and will
have their severity upgraded to serious on August 6th.

Generally speaking DEP17 says that no package should install any files
below /bin/, /lib*/ and /sbin/. Doing so would amount to a symlink vs
directory conflict between base-files which now installs symlinks at the
relevant locations. What happens with these locations depends on the
order of unpacks. In many cases, this is not a problem, because
base-files is essential and thus unpacked early. Other than that,
running dpkg-deb -x foo.deb / causes these symlinks to be overwritten
with actual directories possibly breaking the installation. We currently
have mitigations for these problems in place and plan to drop them after
trixie.

For these reasons, I propose changing section 10.1 and encoding the
avoidance of symlink vs directory conflicts into policy. To get a
discussion going, I suggest the following update.

- 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.


seconded


I suspect that this is not perfect, but it is hopefully good enough for
entering the discussion.

Questions:
 1. Do you agree that policy should be changed?


yes


 If yes:

 2. Do you agree that policy should prohibit installing into aliased
paths?


yes


 3. Do you agree that the current progress is sufficient for changing
policy? If not, when can we change policy?


yes


 4. Do you agree with the proposed wording? Can you suggest
improvements?



looks fine to me


 5. Given earlier disagreement on this matter, should we discuss this
matter in a wider setting such as d-devel?


I don't see any benefit in further discussing this on debian-devel.


Fwiw, I would support Ansgars suggestion to make this a dak autoreject 
(I suppose there are mechanisms to exclude certain packages like 
base-files).



Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074014: encode mandatory merged-/usr into policy

[Holger Levsen]

On Fri, Jun 21, 2024 at 08:27:56PM +0200, Helmut Grohne wrote:
> For these reasons, I propose changing section 10.1 and encoding the
> avoidance of symlink vs directory conflicts into policy. To get a
> discussion going, I suggest the following update.
> 
> - 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.
 
seconded.

> I suspect that this is not perfect, but it is hopefully good enough for
> entering the discussion.

I think it is also good enough to second it.

> Questions:
>  1. Do you agree that policy should be changed?

yes

>  If yes:
> 
>  2. Do you agree that policy should prohibit installing into aliased
> paths?

yes

>  3. Do you agree that the current progress is sufficient for changing
> policy? If not, when can we change policy?

now is fine

>  4. Do you agree with the proposed wording? Can you suggest
> improvements?

yes and I pass.

>  5. Given earlier disagreement on this matter, should we discuss this
> matter in a wider setting such as d-devel?

no, thanks. We have discussed this enough and we have *implemented* the
changes, why should we again discuss whether we want that change?

> Thanks for considering

Many thanks for all your fantastic work here, Helmut!


-- 
cheers,
Holger

 ⢀⣴⠾⠻⢶⣦⠀
 ⣾⠁⢠⠒⠀⣿⡁  holger@(debian|reproducible-builds|layer-acht).org
 ⢿⡄⠘⠷⠚⠋⠀  OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
 ⠈⠳⣄

Suppose a single covid infection takes only two years off your life on average.


signature.asc
Description: PGP signature

Processed: Re: Bug#1074014: encode mandatory merged-/usr into policy

[Debian Bug Tracking System]

Processing control commands:

> tags -1 + patch
Bug #1074014 [debian-policy] encode mandatory merged-/usr into policy
Added tag(s) patch.

-- 
1074014: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074014
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: Bug#1074014: encode mandatory merged-/usr into policy

[Chris Hofstaedtler]

Control: tags -1 + patch

Editors, if tagging + patch is not appropriate, my apologies.

On Fri, Jun 21, 2024 at 08:27:56PM +0200, Helmut Grohne wrote:
> For these reasons, I propose changing section 10.1 and encoding the
> avoidance of symlink vs directory conflicts into policy. To get a
> discussion going, I suggest the following update.

> - 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.

Seconded...

> I suspect that this is not perfect, but it is hopefully good enough for
> entering the discussion.

... including minor changes as necessary.

Chris



signature.asc
Description: PGP signature

Bug#1074014: encode mandatory merged-/usr into policy

[Luca Boccassi]

On Fri, 21 Jun 2024 20:27:56 +0200 Helmut Grohne 
wrote:
> Package: debian-policy
> Version: 4.7.0.0
> X-Debbugs-Cc:
bl...@debian.org,m...@debian.org,mbi...@debian.org,z...@debian.org
> 
> Hi,
> 
> given the progress we have made with /usr-move and DEP17, I think it
is
> time to consider encoding the changes into policy. As of this
writing,
> there are 216 source packages in unstable that still install into
> aliased locations and their number has been dropping since a while.
All
> but very few packages have bug reports of important severity and will
> have their severity upgraded to serious on August 6th.
> 
> Generally speaking DEP17 says that no package should install any
files
> below /bin/, /lib*/ and /sbin/. Doing so would amount to a symlink vs
> directory conflict between base-files which now installs symlinks at
the
> relevant locations. What happens with these locations depends on the
> order of unpacks. In many cases, this is not a problem, because
> base-files is essential and thus unpacked early. Other than that,
> running dpkg-deb -x foo.deb / causes these symlinks to be overwritten
> with actual directories possibly breaking the installation. We
currently
> have mitigations for these problems in place and plan to drop them
after
> trixie.
> 
> For these reasons, I propose changing section 10.1 and encoding the
> avoidance of symlink vs directory conflicts into policy. To get a
> discussion going, I suggest the following update.
> 
> - 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.

Seconded

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1074014: encode mandatory merged-/usr into policy

[Ansgar ]

Hi,

On Sat, 2024-06-22 at 09:42 +0200, Helmut Grohne wrote:
> I have another question. Thorsten Glaser was unhappy about my mksh
> report as he believes that it should be /bin/mksh and not /usr/bin/mksh.
> I argued that the biggest concern is the symlink vs directory conflict
> and he came up with a crazy solution where mksh's data.tar contains
> ./bin/mksh but not ./bin on the grounds that ./bin is provided by an
> essential package in all Debian releases. [...] My
> proposal here would make mksh's approach violate policy. Should policy
> allow Thorsten's approach? It certainly is something that needs to be
> forbidden for any transitively essential package or bootstrapping tools
> fail.

I think it should *not* be allowed to ship files in these locations as
that makes automatically catching regressions harder (among other
things).

We could make dak reject packages shipping files in /bin, /lib*, /sbin
to avoid introducing regressions. I find that reasonable, but others
might disagree what ftpmasters can accept/reject (I would guess at
least one person would in this case...)

Ansgar

Bug#1074014: encode mandatory merged-/usr into policy

[Luca Boccassi]

On Sat, 22 Jun 2024 13:34:23 +0200 Chris Hofstaedtler 
wrote:
> On Sat, Jun 22, 2024 at 09:42:27AM +0200, Helmut Grohne wrote:
> > [..] he came up with a crazy solution where mksh's data.tar
contains
> > ./bin/mksh but not ./bin on the grounds that ./bin is provided by
an
> > essential package in all Debian releases.
> 
> > I think this approach practically solves a significant chunk of the
> > problems listed by DEP17, but it still confuses QA tools and e.g.
> > dpkg -S (maybe more). [..]
> 
> A fully working, unconfused, dpkg is part of what we want. In my
> understanding, we are trying to ship a distribution, IOW a set of
> packages that work *together*.
> 
> If a confused dpkg was okay, then a lot of the work could have been
> skipped.

+1

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Bug#1074014: encode mandatory merged-/usr into policy

[Russ Allbery]

Helmut Grohne  writes:

> Portability is one angle and certainly an important one. Spending
> collective project resources is another one. I argue that changing these
> paths beyond what is technically necessary is not a good use of our
> time. So how about having policy recommend not changing path references
> compared to upstream? I don't think this should be a policy requirement
> as there may be good reasons to deviate and we can rationalize this
> recommendation with the portability and the effort arguments.

Oh, that's an interesting idea.  How about something like:

Since paths either with or without /usr are supported on Debian
systems, maintainers of non-native packages are encouraged to follow
the same conventions as the upstream package when referencing absolute
paths.  There is no need to change upstream code from, for example,
/bin to /usr/bin (or from /usr/bin to /bin) when packaging for Debian.

There is a drawback, though: because dpkg only knows about the usr/bin
(etc.) paths, at least as I understand the current state of things, one
cannot find non-/usr paths with dpkg -S.  Changing all the paths to
include usr/ therefore does solve a usability issue in some cases, so this
trade off is not entirely obvious.

I have lost track of the work on this.  Are there any prospects for dpkg
to know, on Debian systems, that bin/sh and usr/bin/sh are the same thing?

> I have another question. Thorsten Glaser was unhappy about my mksh
> report as he believes that it should be /bin/mksh and not /usr/bin/mksh.
> I argued that the biggest concern is the symlink vs directory conflict
> and he came up with a crazy solution where mksh's data.tar contains
> ./bin/mksh but not ./bin on the grounds that ./bin is provided by an
> essential package in all Debian releases. I think this approach
> practically solves a significant chunk of the problems listed by DEP17,
> but it still confuses QA tools and e.g. dpkg -S (maybe more). My
> proposal here would make mksh's approach violate policy. Should policy
> allow Thorsten's approach? It certainly is something that needs to be
> forbidden for any transitively essential package or bootstrapping tools
> fail.

My inclination is to say no, we shouldn't allow it in Policy.  The release
team can decide whether they care in the case of mksh, and I personally
have a hard time getting that upset about Thorsten carrying that policy
violation in his package when it matters a lot to him and he accepts the
resulting breakage.  But I'm fine with calling it a policy violation: it
breaks other tools, making it work is a level of complexity that we don't
need, and it doesn't, so far as I know, have a strong technical
justification.

-- 
Russ Allbery (r...@debian.org)  

Bug#1074014: encode mandatory merged-/usr into policy

[Chris Hofstaedtler]

On Sat, Jun 22, 2024 at 09:42:27AM +0200, Helmut Grohne wrote:
> [..] he came up with a crazy solution where mksh's data.tar contains
> ./bin/mksh but not ./bin on the grounds that ./bin is provided by an
> essential package in all Debian releases.

> I think this approach practically solves a significant chunk of the
> problems listed by DEP17, but it still confuses QA tools and e.g.
> dpkg -S (maybe more). [..]

A fully working, unconfused, dpkg is part of what we want. In my
understanding, we are trying to ship a distribution, IOW a set of
packages that work *together*.

If a confused dpkg was okay, then a lot of the work could have been
skipped.

Chris

Bug#1074014: encode mandatory merged-/usr into policy

[Helmut Grohne]

Hi Russ,

On Fri, Jun 21, 2024 at 02:06:05PM -0700, Russ Allbery wrote:
> I spent some time thinking about this, since I personally still wish
> people wouldn't write /usr/bin/sh when they mean /bin/sh.  I don't think
> Policy should prohibit this since, among other reasons, we have no
> effective enforcement mechanism and the package will clearly work fine on
> Debian systems.  But it would be nice if people didn't gratuitously break
> portability, admittedly mostly to non-Linux systems at this point.

I agree with your point of view. Elsewhere, when people asked whether
they should move their file references, I argued for "no". I think my
wording does not explicitly discourage those changes but makes it clear
that they are not required. When we suggested changing the dynamic
loader path, there was significant opposition and similarly /usr/bin/sh
was not popular. Hence, there is no way of going without those
links in the foreseeable future. Is there any way we can further clarify
this in the proposed wording?

> That said, I think I convinced myself that this is just not something
> Policy can reasonably address.  We should state the assumption as you
> stated it since that's required for packages to use /bin/sh at all, and
> this probably is not the place to give people portability advice,
> particularly since it only applies to things that might be copied from
> Debian to a non-Debian system and most of those aren't under our control
> and will never be written to Policy anyway.

Portability is one angle and certainly an important one. Spending
collective project resources is another one. I argue that changing these
paths beyond what is technically necessary is not a good use of our
time. So how about having policy recommend not changing path references
compared to upstream? I don't think this should be a policy requirement
as there may be good reasons to deviate and we can rationalize this
recommendation with the portability and the effort arguments. I
recognize that it only partially addresses your portability concern as
native packages as well as packages where Debian is upstream can freely
change those references without violating the recommendation, but those
tend to be a minority and a significant portion of them tends to not
work on non-Debian systems anyway.

> > Questions:

I have another question. Thorsten Glaser was unhappy about my mksh
report as he believes that it should be /bin/mksh and not /usr/bin/mksh.
I argued that the biggest concern is the symlink vs directory conflict
and he came up with a crazy solution where mksh's data.tar contains
./bin/mksh but not ./bin on the grounds that ./bin is provided by an
essential package in all Debian releases. I think this approach
practically solves a significant chunk of the problems listed by DEP17,
but it still confuses QA tools and e.g. dpkg -S (maybe more). My
proposal here would make mksh's approach violate policy. Should policy
allow Thorsten's approach? It certainly is something that needs to be
forbidden for any transitively essential package or bootstrapping tools
fail.

Helmut

Bug#1074014: encode mandatory merged-/usr into policy

[Russ Allbery]

Sam Hartman  writes:
>> "Helmut" == Helmut Grohne  writes:

> Helmut> 5. Given earlier disagreement on this
> Helmut> matter, should we discuss this matter in a wider setting
> Helmut> such as d-devel?

> No, please no!
> If there ends up being disagreement, the TC should use its policy making
> powers and put this to bed.

I forgot about the TC involvement.  This is a better answer than mine.

-- 
Russ Allbery (r...@debian.org)  

Bug#1074014: encode mandatory merged-/usr into policy

[Sam Hartman]

> "Helmut" == Helmut Grohne  writes:


Helmut> Questions: 1. Do you agree that policy should be changed?
Yes.
The TC has effectively set policy here already, and while they did
not  use their power under 6.1.1 to actually officially set project
policy, their position has been clear.


Helmut>  If yes:

Helmut>  2. Do you agree that policy should prohibit installing into
Helmut> aliased paths?

Yes.

3.

Helmut> Do you agree that the current progress is
Helmut> sufficient for changing policy? If not, when can we change
Helmut> policy?

I am not sure I agree with this question, but I agree with a simpler
question: should we change policy now.

Helmut> 4. Do you agree with the proposed wording? Can you
Helmut> suggest improvements?

I have no objections to the wording.

Helmut> 5. Given earlier disagreement on this
Helmut> matter, should we discuss this matter in a wider setting
Helmut> such as d-devel?

No, please no!
If there ends up being disagreement, the TC should use its policy making
powers and put this to bed.


signature.asc
Description: PGP signature

Bug#1074014: encode mandatory merged-/usr into policy

[Russ Allbery]

Helmut Grohne  writes:

> given the progress we have made with /usr-move and DEP17, I think it is
> time to consider encoding the changes into policy. As of this writing,
> there are 216 source packages in unstable that still install into
> aliased locations and their number has been dropping since a while. All
> but very few packages have bug reports of important severity and will
> have their severity upgraded to serious on August 6th.

Thank you again for all the work that you have done on this.  I agree that
we have reached the point in the transition where we should update Policy
to reflect the new requirements of the archive.

> For these reasons, I propose changing section 10.1 and encoding the
> avoidance of symlink vs directory conflicts into policy. To get a
> discussion going, I suggest the following update.

> - 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 spent some time thinking about this, since I personally still wish
people wouldn't write /usr/bin/sh when they mean /bin/sh.  I don't think
Policy should prohibit this since, among other reasons, we have no
effective enforcement mechanism and the package will clearly work fine on
Debian systems.  But it would be nice if people didn't gratuitously break
portability, admittedly mostly to non-Linux systems at this point.

That said, I think I convinced myself that this is just not something
Policy can reasonably address.  We should state the assumption as you
stated it since that's required for packages to use /bin/sh at all, and
this probably is not the place to give people portability advice,
particularly since it only applies to things that might be copied from
Debian to a non-Debian system and most of those aren't under our control
and will never be written to Policy anyway.

> Questions:
>  1. Do you agree that policy should be changed?

Yes.

>  If yes:

>  2. Do you agree that policy should prohibit installing into aliased
> paths?

Yes.

>  3. Do you agree that the current progress is sufficient for changing
> policy? If not, when can we change policy?

Yes.

>  4. Do you agree with the proposed wording? Can you suggest
> improvements?

Yes.

>  5. Given earlier disagreement on this matter, should we discuss this
> matter in a wider setting such as d-devel?

You certainly can, but at this late stage I don't think it would change
anything.  We're already into mass-bug-filing territory and it's going to
be an RC bug, so it's already de facto policy and I don't see a
justification for not making it de jure policy.

-- 
Russ Allbery (r...@debian.org)  

Bug#1074014: encode mandatory merged-/usr into policy

[Helmut Grohne]

Package: debian-policy
Version: 4.7.0.0
X-Debbugs-Cc: bl...@debian.org,m...@debian.org,mbi...@debian.org,z...@debian.org

Hi,

given the progress we have made with /usr-move and DEP17, I think it is
time to consider encoding the changes into policy. As of this writing,
there are 216 source packages in unstable that still install into
aliased locations and their number has been dropping since a while. All
but very few packages have bug reports of important severity and will
have their severity upgraded to serious on August 6th.

Generally speaking DEP17 says that no package should install any files
below /bin/, /lib*/ and /sbin/. Doing so would amount to a symlink vs
directory conflict between base-files which now installs symlinks at the
relevant locations. What happens with these locations depends on the
order of unpacks. In many cases, this is not a problem, because
base-files is essential and thus unpacked early. Other than that,
running dpkg-deb -x foo.deb / causes these symlinks to be overwritten
with actual directories possibly breaking the installation. We currently
have mitigations for these problems in place and plan to drop them after
trixie.

For these reasons, I propose changing section 10.1 and encoding the
avoidance of symlink vs directory conflicts into policy. To get a
discussion going, I suggest the following update.

- 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 suspect that this is not perfect, but it is hopefully good enough for
entering the discussion.

Questions:
 1. Do you agree that policy should be changed?

 If yes:

 2. Do you agree that policy should prohibit installing into aliased
paths?
 3. Do you agree that the current progress is sufficient for changing
policy? If not, when can we change policy?
 4. Do you agree with the proposed wording? Can you suggest
improvements?
 5. Given earlier disagreement on this matter, should we discuss this
matter in a wider setting such as d-devel?

Thanks for considering

Helmut