Re: RFS: libconfig
Jan Hauke Rahm wrote:
>>> [snip]
>>>
>> 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.
>>
Hmm... think I didn't quite convey the proper situation here ...
> I think you're having a big misunderstanding of the Debian archive here.
> If you uploaded the new version of the *same* (source) package
> (libconfig here), what source package would then provide the binaries
> the old version previously provided?
only the previous one, which will not be built anymore. That is, none.
I was talking about the installed versions, of course.
> A new version means the old one is
> going to disappear. There is no RoM for binary packages.
>
Indeed. Dependent packages will need to build against the newer soname.
This is the reason why -dev packages provide a "libconfig-dev" package.
However, since there are no libs depending on libconfig, I guess a
transition "proper" is not needed. I am notifying the maintainers of
dependent packages of the soname bump so that they can rebuild against
the newer library (thanks for the pointer).
In any case, is there any other approach which you recommend above this?
having -dev packages which provide libconfig.so "co-installable" (i.e.
not conflicting against each other) is certainly not a solution. Nor can
I provide libconfig8 anymore now that upstream has published an
incompatible API and changed the soname.
Regards,
J.L.
Reply to: