Re: RFS: libconfig
Jan Hauke Rahm wrote:
> [snip]
>>> Now that you change the soname and all, did you check the reverse
>>> dependencies?
>>>
>> I am not removing any existing soname for now; the new upload simply
>> carries a new soname. Nor do I conflict with any previous soname:
>> Reverse dependencies won't stop working until the previous sonames are
>> removed.
>>
>
> Ermm, you're not removing what? Your new version 1.4.4-1 provides
> different packages names, i.e. libconfig9 instead of libconfig8 (and
> others accordingly).
>
Yes, but I haven't filed any RoM nor do my packages conflict with the
previous soname.
This means that, while I won't provide any newer version for the
previous soname (which I can't since upstream changed the API), *both*
sonames can be installed at the same time. This means existing binaries
can continue working until recompiled.
>> However, there are no reverse-depends in the Archive as of now.
>>
>
> Sure?
>
> ,----
> | ?0 jhr@ca:pts/9 [/tmp/c] $ apt-cache rdepends libconfig++8
> | libconfig++8
> | Reverse Depends:
> | libconfig++8-dev
> | ldc
> | flush
> | ?0 jhr@ca:pts/9 [/tmp/c] $ apt-cache rdepends libconfig8
> | libconfig8
> | Reverse Depends:
> | qwo
> | libconfig8-dev
> `----
>
:-O
I am *most* flattered by this.
I only packaged libconfig for my own use and to have it available from
Debian. I didn't check this time since I assumed it hadn't changed
since. Having users actually using your packages is quite nice indeed :-)
> Looking at their build dependencies, it seems they depend on
> libconfig8-dev (libconfig++8-dev respectively) and thus need a source
> upload to depend on either libconfig9-dev or a more generic
> libconfig-dev if you provide one.
>
I do provide libconfig-dev, but a sourceful upload is needed in any
case, since the API changed (that's the reason for a soname bump, after
all.....)
>>> Do they need binNMUs or even source uploads? Do they still work?
>>>
>> The soname bump would have meant recompilation at the very least (most
>> probably even source changes, since an API change also happened).
>> In any case, the addition of symbols files makes backporting and/or
>> upgrading easier, since ld.so can use the additional information (since
>> libc6 2.3.6ds1 if memory serves me well) to satisfy symbol dependencies.
>>
>
> True but the binaries using the lib need to be compiled against it with
> symbols in order to use them => re-compiling is needed.
>
For newer versions, yes, of course.
Existing binaries will continue using the symbols in the existing
library (soname 8) and newer compilations will automatically pick
symbols from the most recent, as expected.
> I just now saw it... you're actually conflicting with libconfig9-dev and
> libconfig++8-dev. Apart from that being total nonsense, what are you
> trying to achieve? And how come you're thinking you're not conflicting
> with previous versions?
Nonsense?? There must be something I don't understand, then ....
How is a *sane* system going to cope with two different packages
providing the same .so symlink ?
I mean:
- libMyLibN provides /usr/lib/libMyLib.so.N.*
and libMyLibN-dev provides libMyLib.so, which is a symlink to libMyLib.so.N
when linking, ld resolves -lMyLib to libMyLib.so.N
upon runtime, ld.so resolves libMyLib.so.N to libMyLib.so.N.z and the
program runs
- libMyLibM would provide /usr/lib/libMyLib.so.M.*
and the corresponding libMyLibM-dev shall provide libMyLib.so ->
libMyLib.so.M
if both were to be co-installable, which library should get pointed at?
Hence, the maintainer of a depending package shall build-depend on
either libMyLibN-dev or libMyLibM-dev, so that the linker can pick the
intended soname/API at build time ( NEEDED entry in the ELF header )
Then, the runtime linker will resolve the symbols at runtime so that the
executable will run properly
Please enlighten me if there is something I haven't grasped yet, but I'm
quite sure about these points (and have in the past been "reprimanded"
by fellow DDs for trying to remove a previous soname by having
conflicting -dev packages)
In any case, thanks in advance for your time.
Best regards,
J.L.
Reply to: