Hi Ted, On Wed, Jul 12, 2023 at 10:23:08PM -0400, Theodore Ts'o wrote: > For those packages that are likely to be backported, would ti be > possible provide some tools so that the package maintainers can make > it easy to have the debian/rules file detect whetther it is being > built on a distro version that might have split-/usr, or not, or > whether we the package needs to do various mitigations.... or not?
Please allow me to go into a little more detail as to why we get into a problem for backports and then circle back to your question. I currently imagine (and this has been vaguely circulated on d-devel a number of times) to facilitate the canonicalization using debhelper. We have minor disagreements on how exactly that should work. Let me give my preferred version while keeping in mind that this is not yet consensus: debhelper gains a new addon. It could be called usrmerge or something. If you enable usrmerge, debhelper would perform the path canonicalization for you. Your dh_auto_install could install to canonical and aliased paths, but the .deb would be canonicalized. Thus, you can easily opt into it by saying Build-Depends: dh-sequence-usrmerge. We may also add this addon to a new compat level as we expect that most packages in trixie will need it. Thus we're changing it from opt-in to opt-out. While you can merge like that, a number of packages will notice that you can simplify your packaging by e.g. changing --prefix=/ to --prefix=/usr or something similar and doing that canonicalization at dh_auto_install time. In doing this, they loose the information about how files were previously being split to / and /usr. For instance systemd needs extra effort to support the split layout and that support is going to be deleted soon. I expect this to happen for most packages. And this is the part that makes backporting hard in a way that honours the moratorium for bookworm-backports. I'm sorry for not having considered the use case of using a single debian/ directory tree for multiple distributions and releases, but it is fairly obvious in hindsight. Is checking for the presence of usr-is-merged good enough for your case? What I imagine you doing here is generally supporting split-/usr in e2fsprogs (for as long as you want to support building e2fsprogs on any system that needs such support) and then telling debhelper to enable the usrmerge addon whenever you don't need to support split-/usr. A fairly obvious candidate check would be checking for the presence of usr-is-merged, but while bookworm always contains that, we effectively want it to support split-/usr to facilitate upgrades. Some of the mitigations require the addition of a usrmerge-support package whose preinst will unconditionally reject unmerged systems. Would that be a suitable condition? > The point is before we lift the freeze, perhaps we can provide some > tools that make it easier for package maintainer to only "make > split-/usr support vanish" conditionally, so as to make life easier > for people who are doing the bookworm and bullseye backports? If going with the debhelper addon and keeping split-/usr support in the particular package otherwise, the one backporting can simply pass --without usrmerge to dh and be done. If using the usrmerge-support package as condition (could even be done inside debhelper), that would become automatic. > I don't mind keeping some buster and bullseye and bookworm schroots > around, and doing test-builds of the packages I build, and then making > minor adjustments as necessary to make sure things still work. > Combined with some test automation so that we can test to see whether > a package about to be uploaded to bullseye-backports won't break on a > split-/usr machine, and this should be quite doable. The real problem I see with such backports is a different one though. Consider the case where we reorganize a package (move files between packages) during the trixie cycle. In the normal scheme of things we have this sequence: * bookworm v1: split-/usr + original file layout upgrade * trixie in progress v2: merged-/usr + original file layout upgrade * trixie in progress v3: merged-/usr + reorganized package upgrade * trixie in progress v4: merged-/usr + reorganize again That reorganization may trigger the need for applying a mitigation and the main plan is to only apply such mitigations as-needed. Now when you backport this, you'd revert the merged-/usr part, so instead you end up with this: * bookworm v1: split-/usr + original file layout upgrade * bookworm-backports v2~bpo: split-/usr (reverted) + original file layout upgrade * bookworm-backports v3~bpo: split-/usr (reverted) + reorganized once package upgrade * trixie v4: merged-/usr + reorganized again This upgrade sequence may require a different mitigation, because we swapped the order of canonicalization and reorganization. I have not yet come up with an actual test case where this breaks, so maybe I'm really wrong worrying about this. That v3~bpo package may contain locations (according to the dpkg db) that have not been seen in any of the non ~bpo versions. The v4 package would have suitable Replaces for the v3 one but those may be ineffective for v3~bpo and the existence of v3~bpo may require additional mitigations in v4 to facilitate such upgrades. So in essence, uploading a package to bookworm-backports might break upgrades from backports to nextstable in a way that you may not even seeing at the time you upload to bookworm-backports. Therefore a maintainer needs in unstable needs to be aware of the backport and possibly add supporting mitigations to their v4 upload. In the best case, this situation is so rare that we see 0 instances during the trixie cycle, but we should be aware that this may happen. Helmut
