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

2024-06-21 Thread 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

2024-06-21 Thread 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

2024-06-21 Thread 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

2024-06-21 Thread 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