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
