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
