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

Re: Debhelper and /lib/systemd vs /usr/lib/systemd



>>>>> "Niels" == Niels Thykier <niels@thykier.net> writes:

    Niels> If the project consensus of this discussion is aligned with
    Niels> the belief that we should block decentralized volunteer work
    Niels> on the transition, I will respect the decision.

I was really frustrated reading that, and I hope that my reading is more
loaded than you meant.
If what you're saying is that you'll respect it if the project consensus
is that  individual package maintainers should not move paths around at
this time, then I think that's the key question.

I'll point out that we get a lot of value even if we don't move paths
around in packages.
In particular, we get a uniform environment where we can  depend on a
single directory layout.
That removes classes of bugs even if we don't get to update canonical
paths.



What I originally heard in your statement was  a consensus that volunteers are not needed,
and I don't think anyone support that.

I think there are several ways in which volunteers are needed:

* Working on figuring out how to trigger the transition.
Ideas included so far are to make usrmerge transitively essential, to
include such code in dpkg, or to detect non usrmerged systems and force
the administrator to do something manually.

* Figure out whether we'll require build chroots to remain
  non-usr-merged in bookworm (thus requiring some way to generate such a
  system) or whether we'll somehow guarantee that usrmerge transition
  happens at the beginning of the upgrade.

* Finish out the discussion Simon Richter and Ted Ts'o are having
  exploring changes in dpkg behavior.

* Write patches for dpkg.
I appreciate that getting those patches merged may be a challenge, but
the situation is different with patches in hand.

Yes, a lot more of these volunteer tasks are about talking to people
than normal package maintenance.
And some of them are kind of tricky.  I don't even know who makes the
decision about what the upgrade procedure is between releases in Debian.
I mean I can guess to some extent the release team is involved and to
some extent the release notes authors are involved.
And I'd probably talk to the apt maintainers too.
But I'm honestly not sure how we'd evaluate a proposed change to the
upgrade procedure.


Reply to: