Guillem Jover

I think that the vendor specific config/behavior could be integrated upstream by using the dpkg-vendor logic. So by default it would use the default vendor, which could be overridden via...

This is now implemented in git main, you can use USE_SYSTEM_ROCKSDB=yes to avoid using the vendored dependency. So I guess this can be closed?

For (Debian) packages we use for work I started unvendoring these. And was planning on doing the rest to be able to provide a patch for official Debian packages (https://bugs.debian.org/1067413),...

@asgh Hey! Perhaps you could give the referenced PR a try to see whether that fully solves your issues?

BTW start-stop-daemon (from dpkg) used on sysvinit, on Linux or other kernel-based systems, does support the readiness protocol too. See the `--notify-*` options in https://manpages.debian.org/start-stop-daemon.8.

> > The problem is that these structures are public, and there are inline > > functions making use of the old or new members depending on what > >...

I might have missed some codepaths, but I guess I could do the following: ``` diff --git i/debian/liburing2.symbols w/debian/liburing2.symbols index 9c20795..19cac25 100644 --- i/debian/liburing2.symbols +++ w/debian/liburing2.symbols @@ -10,16 +10,16 @@...

> Not familiar with the SOVERSION. Does that imply bumping the version to 3.x? Yeah the SOVERSION is commonly used to refer to the version part of the SONAME, so...

> Another way would be to have only inline functions and no .so file at all anymore... While certainly an option, this would be equivalent to bumping the SOVERSION on...

Thanks for working on this! I locally added gosop support into the SOP backend in dpkg, but it is still failing due to at least the Armor Headers issue I...