Re: Handling library with unstable ABI in experimental -- suggestions?
On Sat, 24 Nov 2018 at 23:45:28 -0500, Roberto C. Sánchez wrote:
> I am curious if anyone has suggestions for naming the library package in
> experimental in such a way that it handles the currently unstable ABI
> and also leaves the way clear for a properly named library package once
> the ABI stabilizes and it becomes appropriate to upload to unstable.
One thing you could do would be to generate a versioned Provides for
a virtual package name that incorporates the upstream version, perhaps
something like libfoo0-0.1.2 (= ${binary:Version}) if the library
is libfoo.so.0 version 0.1.2-3, then make the .symbols file generate
dependencies on that virtual package name instead of or as well as the
library package's actual name?
If there are dependent packages also in experimental, then every upload
would need a batch of binNMUs (or quite possibly sourceful uploads if
the dependent packages make use of the ABIs that broke), but that's
going to be the case anyway for any shared library with an unstable ABI.
In the release that has a stable ABI, you could set the dependency for
all symbols to be libfoo0 (>= the first stable release), so that old
unstable versions won't satisfy the generated dependency.
I've done this for gtk+4.0 in git, although not uploaded the result
yet. In fact gtk+4.0 also changes its SONAME with every upstream release
at the moment, currrently libgtk-4.so.0.9400.0 for version 3.94.0,
so I used libgtk-4-0.9400.0 for the virtual package; but the packaging
has been done as though it was libgtk-4.so.0, which will be its stable
SONAME eventually.
> That said, upstream intends to declare a stable ABI in some months,
> after which the ABI, SONAME, etc. will be managed sensibly. The upload
> to unstable will not happen until that has been fully sorted out.
This is basically the same situation as gtk+4.0.
smcv
Reply to: