Bug#509933: versioning SONAMEs of shared libraries is not clearly recommended
"Giacomo A. Catenazzi" <cate@debian.org> writes:
> Russ Allbery wrote:
>> I read through the shared library sections of Policy a few times last
>> night and can't find anywhere where Policy unambiguously recommends
>> always including a version in SONAME for public libraries. If you
>> don't have a version, you can't represent the library in the shlibs
>> format, so there's an implicit recommendation, but I think it would be
>> better to make it explicit.
>
> I think the first sentence of 8.1 with the footnote 47 give an
> answer, but: a footnote (IMO) is not normative, and a "a good idea"
> is too weak.
>
> [8.1]
> The run-time shared library needs to be placed in a package whose name
> changes whenever the shared object version changes.[47]
>
> [47]
> Since it is common place to install several versions of a package that
> just provides shared libraries, it is a good idea that the library package
> should not contain any extraneous non-versioned files, unless they happen
> to be in versioned directories.
Oh, hm, yes, there's a stricter statement of the same thing now in section
8.2:
If your package contains files whose names do not change with each
change in the library shared object version, you must not put them in
the shared library package. Otherwise, several versions of the shared
library cannot be installed at the same time without filename clashes,
making upgrades and transitions unnecessarily difficult.
I should fix the footnote to make that consistent.
I don't know if we should make a special case for the kdeinit libraries,
or in general how we should deal with that.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: