[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEP 17: Improve support for directory aliasing in dpkg



On Sat, 6 May 2023 at 11:00, Simon McVittie <smcv@debian.org> wrote:
>
> On Fri, 05 May 2023 at 23:11:54 +0100, Luca Boccassi wrote:
> > In practice, I suspect that out of ~2000 packages shipping bin/ sbin/
> > lib*/, only a small fraction would end up needing to further move
> > files out to other packages
>
> I think the most common case for this is likely to be systemd system
> units, which are currently in /lib/systemd and are sometimes moved between
> binary packages. Splitting out dbus-system-bus-common during the bookworm
> release cycle is a recent example, but it also seems reasonably common
> to move systemd units around as part of having a distinction between
> "the ready-made system service" and "the binary you can run by hand"
> (see apache2 vs. apache2-bin).
>
> udev rules are in a similar situation: consumed by an important system
> service, but shipped by any random package that wants to adjust its
> behaviour.
>
> Two things about systemd units make them a relatively difficult case
> for distro-wide changes like this:
>
> For /bin, /sbin and to a lesser extent /lib/TUPLE, we can often assume
> that only "core" packages (whose maintainers should be paying attention to
> subtleties like this) are affected by any change, because the historical
> definition of those directories was "just enough to boot the system or
> do disaster recovery", minimizing what should be there; but the number
> of packages that touch /lib/systemd is rather large, and a lot of them
> are leaf or near-leaf packages.
>
> Also, they're managed (and sometimes installed) by debhelper, which
> needs to be able to do the right thing relatively automatically. For
> example, if maintainers need to be able to take some special action at
> the point at which their /lib/systemd units move to /usr/lib/systemd,
> then I think debhelper installing into /usr/lib/systemd would have to
> be gated by a compat level change.

Yes, I suspect you are right that it would be the bulk of the leaf
packages. But still shouldn't invalidate what I mentioned? As long as
they are kept in the same package, there shouldn't be a need for
diversions. And if they need to be moved in this cycle, the diversion
dance will be needed. Do you see any problems with this approach?

Kind regards,
Luca Boccassi


Reply to: