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

Reply via email to