TL;DR: Should we hold off on moving stuff from / to /usr in packages
until we develop our plan?
If so, how do we communicate that to people?
>>>>> "Russ" == Russ Allbery <rra@debian.org> writes:
Russ> Simon Richter <sjr@debian.org> writes:
>> It is less nonsensical because usrmerge exists, since we
>> presumably don't want to keep the /bin paths in the packages, so
>> at some point we need to move /bin/foo to /usr/bin/foo inside a
>> package. That is safe with current dpkg, as dpkg will not delete
>> /bin/foo if it has the same inode as a just-unpacked file.
Russ> [...]
Russ> I think this implies that writing something in Policy about
Russ> this would be premature. The issues you raise are related to
Russ> something new that is being discussed and would be part of a
Russ> migration plan to a merged /usr world.
Russ, I agree with you that it's premature to document this in policy.
However, Simon has raised what I think is a credible argument that it
is harmful to perform both / -> /usr transitions and to move files
between packages in the same release.
My take away from that is that it may be harmful to move a bunch of
stuff from / -> /usr until we have a plan, and that maintainers should
actively be discouraged from doing so.
I think we should get people to hold off at least until we have a
consensus on that point.
And this is by no means theoretical.
As was discussed here, recent debhelper (has or at least had) changed
from installing systemd units in /lib/systemd/system to
/usr/lib/systemd/system.
That is totally fine interms of usermerged stuff, but sets up a
potential problem .
Suppose we have a program foo that ships a daemon and also a systemd
unit to run it.
Later we discover that foo is kind of useful in desktop situations and
other situations where it wants to be started as needed and possibly
not even by systemd.
So, we want to split out the foo package into foo containing the daemon
binary and foo-system (recommended by foo) containing the systemd unit.
The maintainer may not even be thinking about how debhelper moved around
the unit file.
foo-system replaces/breaks the old version of foo.
I think the following series of operations would result in the unit file
disappearing on a usermerged system:
* user has old foo with /lib/systemd/system/foo.service
* user attempts to upgrade and installs foo-system as part of upgrade
* foo is deconfigured because of the breaks on foo-system
* foo-system is unpacked, including
/usr/lib/systemd/system/foo.service. On the usrmerged system, that
overwrites the existing foo.service since dpkg doesn't know about the
aliasing
* foo is upgraded. From dpkg's standpoint it looks like
/lib/systemd/system/foo.service disappeared, but since the file still
exists it is removed.
So the user ends up with no unit.
I think this is particular insidious because the maintainer might not
even know that they had moved files from / to /usr, or if they knew they
might have not been paying enough attention to provide special care.
Do people agree that we want to hold off on this sort of thing until we
get a plan?
Attachment:
signature.asc
Description: PGP signature