Bug#1051237: transition: move files from / to /usr to finalize /usr-merge
Hi Sebastian,
On Tue, Sep 12, 2023 at 09:24:45AM +0200, Sebastian Ramacher wrote:
> thanks for the detailed explanation.
thanks for following up in detail.
> On 2023-09-04 22:33:54 +0200, Helmut Grohne wrote:
> Skipping all the technical details, as I would not classify this as a
> transition where the release team needs to be involved. We can of course
> help with the rebuilds of the affected packages, but this change does
> not require us to check for outdated binary packages in testing or to
> make sure that everything migrates together.
It certainly is not a usual transition and also will not migrate
together. In that sense, I agree. Yet, I think this is something that
the release team wants to know is going on and consider how it interacts
with other transitions (e.g. time64). In essence, I think we agree. :)
> For the systemd change, the following steps should be enough in general:
>
> 1. debhelper with support for service files in /usr migrates to testing.
done
> 2. Rebuild packages which currently have their service files.
A guinea pig package "location" has been uploaded with support from
Jochen. I don't have numbers on the number of packages that manually
install to /lib, but it is many. So this will likely require collective
effort rather than me sending patches.
> 3. debhelper installing service files to /usr per default migrates to testing.
I'm unsure when to do this as I see a moderate risk here. The dumat
report currently looks promising, but we also might run into a stream of
RC bugs.
> 4. Rebuild all packages with service files.
I note that the deadline for this practically is trixie and that this
doesn't really block any other part of the transition.
> For packages where these steps are not enough, bugs are filed along
> while preparing 1. and 3. This will include all packages which include
> service files in Arch: all packages as we cannot binNMU them.
>
> Depending on the number of packages in step 4., this would ideally not
> be done during the time_t transition to avoid any surprises.
I'd hope half of the packages that could be binNMUed have a maintainer
upload in the relevant time frame. That also has the benefit of
spreading any bad effects over time rather than breaking the archive at
once.
Regarding the time64 transition, I expect bad interaction. Essentially,
time64 will restructure a large amount of packages (moving files from
one binary package to another retaining the name on 64bit architectures
and thus employing Replaces). As we combine this with mass-moving files
from / to /usr, we get exactly that DEP17-P1 scenario that the
moratorium was meant to prevent. This interaction is not avoidable by
clever timing, because it affects upgrades from bookworm to trixie. I've
talked to Steve already to make him aware. The current plan is to just
handle this on an individual level and applying the proposed mitigations
to issues detected by dumat.
> The other / to /usr file moves will need uploads anyway. So we cannot
> help here (except for monitoring the status of the bugs during the
> freeze). Regarding the move on d-i's side, please coordinate this change
> with Cyril. From your explanation it is however not clear to me whether
> we are blocked on finishing the /usr-merge change in the main archive by
> d-i or not.
Let me clarify that in filing this transition bug, my intention was not
to get assistance from the release team, but making you aware of what is
going on and giving you a reasonable chance to object.
The d-i part is rather critical from my point of view. Since d-i still
is unmerged, moving files from / to /usr in udebs is likely to break
d-i. This explicitly does not cover systemd units though when systemd
drops support for split-/usr (next release), d-i will likely be broken
anyway. So until d-i is fixed, the remaining moratorium should cover at
least all source packages that build udebs.
Some of this may be overly cautious, but I'd rather be cautious than
temporarily break the archive and that way cause lots of work to
unsuspecting developers. Developer time is a scarce resource and some of
what we're up to has a risk of consuming lots of that.
In any case, I take that at least Paul and Sebastian do not veto moving
forward with this. Cyril will probably take some time, but will unlikely
comment non-udeb aspects. No clue about Graham. I therefore intend to
slowly move forward with the actual conversion in a way that causes
least possible disruption and will keep you updated when I expect
non-trivial disruption.
Helmut
Reply to: