Re: Need help with Multi-Arch in systemd

[Guillem Jover <guillem@debian.org>]

On Wed, 2021-07-14 at 11:59:11 +0100, Simon McVittie wrote:
> On Thu, 08 Jul 2021 at 23:03:48 +0200, Michael Biebl wrote:
> > [a separate libsystemd-shared-249 .deb] would also mean, that on every
> > new upstream release, systemd would have to go through NEW
> 
> It seems like we're rejecting a good technical solution because
> social/organisational factors block it (namely, new binary packages
> triggering manual review from the ftp team even if there has not been
> any significant change in how the package is organised, resulting in
> manual review being artificially frequent for libraries that happen to
> break ABI a lot, but infrequent for packages that aren't libraries or
> don't break ABI).

Yes. I was mentioning exactly this the other day on the
#debian-bootstrap IRC channel.

In addition having this automatic support could make life easier for
many other potential packages.

> This seems like a side-effect of the ftp team's two gatekeeping roles
> (legal review and managing the namespaces of source and binary package
> names) both having the dak override file as their implementation, rather
> than necessarily anything that was designed or intended.

Yes, plus section and priority-spaces. But then, I don't see why a binary
package rename should trigger a new legal audit.

> Would it be feasible for dak to have a list of binary package name
> regexes mapped to a source package and a section/priority, and auto-accept
> packages from the given source package that match the regex, assigning
> the given section/priority, without manual action? That would let the
> ftp team pre-approve src:systemd to ship /^libsystemd-shared-[0-9]+$/
> in libs/optional, for example.

What I had in mind was that DAK would gain support for automatic
ACCEPT of binary package renames due to SONAME version bumps,
something like this:

  * If the new bin:lib<name><version-b>:
    - replaces an existing bin:lib<name><version-a> from the same
      source, where <version-a> is lower than <version-b>.
    - contains a shared library mapping to that package name.
    - is in section */libs or */oldlibs.
  * Then → auto-ACCEPT, pre-filling the new section/priority from the
    old binary package.
  * Otherwise → NEW.

I guess it could potentially be further extended later on to cover
other safe non shared library cases.

But if that's too much to ask, either due to implementation or policy
concerns, I'd take an explicit allowlist letting specific cases
through, such as the systemd one, instead of having to settle for
either suboptimal or wrong solutions for the problem at hand, due
to the currently required workflow being too cumbersome.

Thanks,
Guillem