Re: /usr-merge: continuous archive analysis
Hi Andreas,
On Sun, Aug 06, 2023 at 06:44:47PM +0200, Andreas Metzler wrote:
> Somehow related: If I introduce a new systemd unit should I work
> around dh_installsystemd and ship it in /usr/lib/systemd/system/?
Doing this is extra work now. If done correctly, it is compatible with
the file move moratorium. Some packages declare a trigger interest for
the aliased location and will have their triggers missed as you move to
/usr, but I've already filed bugs for all affected packages so this is
temporary at best. In general, I am in favour of this.
> At first glance it seemed like a good idea (not adding to the problem)
> but doubt there is real benefit. - Another binary package in the same
> source already ships a unit that will need to be moved so we will need
> to use $magic anyway. FWIW I would have used something like this:
I also agree with this with a little caveat. Quite a number of available
mitigations incur a cost per file. So by moving that secondary unit now,
you may be lucky and avoid a mitigation for it later.
> override_dh_installsystemd:
> dh_installsystemd
> mv debian/foo/lib/systemd/system \
> debian/foo/usr/lib/systemd/
Consider execute_after_dh_installsystemd. Other than that, this is the
way to go. If you were to move before dh_installsystemd you'd miss
maintainer scripts activating/starting your unit.
> (I am assuming dh_installsystemd would not start installing stuff into
> /usr/lib without a dh_compat bump.)
We don't have consensus on this yet, but I agree with you here. My
preferred way of implementing the merge in debhelper is adding a new
dh_usrmerge that would perform the merge. It would come with a sequence
addon "usrmerge" which would be enabled in a new compat level. Once the
moratorium is lifted, you can:
* opt in: Explicitly call dh_usrmerge
* opt in: Build-Depends: dh-sequence-usrmerge
* opt out: Bump compat level and pass --without=usrmerge to dh
The downside of this approach (and why people disagree with it) is that
we need at least one upload with source changes for every affected
package. Yes, this does mean 2000 uploads.
This is not backed by code yet, but you may disagree with it already.
Helmut
Reply to: