On Wed, Jul 12, 2023 at 03:34:38PM +0200, Helmut Grohne wrote: > ## No good solution for bookworm-backports > > There is one major issue where I don't have a good answer: > bookworm-backports. When this originally surfaced, Luca Boccassi > suggested that we do not canonicalize in backports. That's easier said > than done as the support for split-/usr will soon vanish from packages....
> ... Adding such intrusive changes to > bookworm-backports and pulled by a significant fraction of backports > sounds bad to me. The alternative here is that backporting will become a > lot harder as those performing backports would have to undo the > canonicalization. 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? I've done that by hand, since for a while I was maintaining the debian directiry in e2fsprogs (yes, I know, bad bear, you're not supposed to do that), but one of the reasons why I did this is that I had *one* set of debian files that would successfully build on Debian stable, Debian testing, Debian oldstable, Debian oldoldstable, some random Ubuntu LTS versions, *and* Google's Prod-NG[1] variant. That's because I wanted to allow people to check out the latest version of e2fsprogs from the git tree, and build it on a variety of distro versions, even though e2fsprogs upstream had added some new binaries, or some new config files, since Debian oldoldstable had been released. [1] https://marc.merlins.org/linux/talks/ProdNG-LinuxCon2013/ProdNG.pdf I haven't kept up with it, since it's not really needed any more (Google has since migrated away from ProdNG to something else, and I stopped caring about Ubuntu LTS :-), but the hardest part was dealing with various different versions of debhelper. 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? 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. Of course, this may be more effort than people are willing to do.... - Ted