Re: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not
On Fri, Jan 21, 2022 at 01:28:54PM -0500, Scott Kitterman wrote:
>
> 1. When the SO name changes and the binary package name is adjusted
> accordingly, it is not super rare for the maintainer to mess something up in
> the renaming and end up with an empty binary package, which does no one any
> good. I note that for debhelper compat 15 there appears to be some related
> work in progress. Perhaps this is, or can be extended to be, sufficient to
> eventually make this kind of error a thing of the past.
Can we have better automated tooling, either in Lintian, or in when
source packages are rebuilt, that can take care of this?
The other thing that's perhaps considering here is that unfortunately,
there are some upstreams that are extremely irresponsible with library
ABI backwards compatibility, where they bump the SONAME essentially at
every release. I recall one extreme case a few years ago where there
were over ten(!) SONAME bumps for a particular library over 12 months.
The problem with this is that it makes for a massive headache when it
comes to security updates. The claim for why we want to use shared
libraries, despite the library dependency hell problem, is that when a
security problem gets fixed, all we need to do is to upload a new
shared library package, and all of the packages which depend on it
automatically get updated. Well, if during the course of a testing
release, we have binary packages depending on libshaky3, libshaky5,
libshaky6, libshaky7 and libshaky8, now if there's a long-standing
security bug that gets fixed, it's not necessarily the case that when
the Debian maintainer which uploads an updated libshaky source
package, which might result in binary packages libshaky-dev,
libshaky-bin, and libshaky8, that there will be updates for
libshaky{3,5,6,7}.
Now that we are requiring source uploads for everything entering
testing, there's easy answer to this --- which is to simply have an
automated system which rebuilds all of the packages that have a
build-depends on libshaky-dev, so all the packages will now have a
dependency on libshaky8. Huzzah!
But if we're going to do that, then we could also just support static
libraries, and just rebuilt all of the pacakges that link statically
with libshaky, thus solving the security argument for shared
libraries. This also avoids the fairness problem where some packages
are reguarly going through ftpmaster review, and others aren't...
Just a thought....
- Ted
Reply to: