Re: Debhelper and /lib/systemd vs /usr/lib/systemd
Sam Hartman:
>
> 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
>
As I understand it, the issue does not depend on whether "usrmerge" is
run before or after installing the "/lib" version of "foo". On that
assumption, running "usrmerge" as a part of the upgrade and "cleaning
up" in bookworm+1 is liable to exactly the same risk as before.
Which means that we are likely "just" debating on when we want to risk
to occur. The difference for me being that people would forgot about
this issue in bookworm+1 and assume that migration is over with no risk
left.
On that front, I prefer to take my chances with breaking bookworm while
it is fresh in our minds rather than breaking bookworm+1 when every body
forgot about it.
That said ...
> * 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?
>
This strongly depends on:
* Who volunteered to be the "we" that provide this plan?
* When is "until" we have a defined plan?
For concrete values of those definitions, I can be convinced to stop
further changes and rollback the systemd / -> /usr change. However, as
long as these definitions are variations of "somebody" or "everyone" or
"the project" and "eventually" or "when it is ready", then I am not
convinced that waiting is the right option.
For now, I will hold on further "/ -> /usr" changes in debhelper, but I
am not convinced that I should actively rollback the changes already made.
Thanks,
~Niels
PS: Guesstimates suggests that there 16.5 months until the transition
freeze assuming the release team keeps the current cadence.
Reply to: