[csw-maintainers] commentary on shared library naming proposal

[Maciej (Matchek) Blizinski]

No dia 16 de Novembro de 2010 00:20, Philip Brown <phil at bolthole.com> escreveu:
> This is starting off a fresh thread, on the proposal being suggested
> around naming of packages, that have shared libraries in them.
>
> Maciej was kind enough to write up a web page for it, here:
>
> http://wiki.opencsw.org/packaging-shared-libraries
>
> I have made some very minor updates to it, and corrected the naming
> length "32" to "29" .
>
> I then added some areas of concern that I have, to the bottom of the page.
>
> I was originally going to quote them here, but they have become rather long :-/
> So perhaps they are better read in the full context of the wiki page, above.
>
>
> I will also mention, given that Maciej gave the debian sharedlibs
> policy (section 8.1) as a reference, if we abided by the WHOLE text of
> that section. Again, my further notes on that, are at the bottom of
> the wiki page.
>
>
> General comment I did not add into the wiki: I do not see having "more
> packages" as a good in and of itself (and neither does Debian, as I
> reference in the page).

It can be viewed as both good and bad, depending on the context.  We
can remove this point if you wish.

> If upgrading "libcups" -- what was previously a single package -- now
> takes downloading and cycling through (pkgrm, pkgadd) **6** times... I
> dont think this looks good to our users.

Granted that 6 packages will take slightly longer to install, I don't
see why is that a problem.

> What to do when a software package has its common name as "libxyz", and then also contains a "libxyz.so.#" ?

You'd follow the recommendation and have CSWlibxyz# with the library,
CSWlibxyz-devel with headers and the .so file, and if there's anything
left, CSWlibxyz-doc, etc.

> People will usually expect to find the package by simple name. Do we provide a ghost "libxyz" package that depends on the longer named one? Or expect that our users will educate themselves (usually a losing proposition)

They will probably do something like "pkgutil -a libxyz" and find out
the package names.

> What to do when a software package is primarily a library, but is more commonly known by a shorter name? EG: "ldns", which technically is short for "libdns", and mostly just provides a "libdns", but its software name is specifically "ldns" NOT "libldns". :: http://www.nlnetlabs.nl/projects/ldns/

Follow the recommendation:

CSWldns-devel with the header files
CSWlibldns1 with /opt/csw/lib/libldns.so.1
CSWldns(-.*)? if there's anything left (docs, tools, etc)

> Is it really neccessary to add a "1" to well-known libraries, that have a very small likelyhood of changing, and so do not present an issue to the stated goals? ie: "libldns" -> "libldns1" :: is that really neccessary or even useful?

Everything will end some day, and so will libldns.so.1.  When that
happens, future maintainers will be grateful that we've made it easier
for them to phase it out.

While it's not strictly necessary to add the "1", I see no reason to
object to that if a maintainer thinks it's a good idea.

> What about when the software is actually known as "libFoo", and is at version X, but the shared lib of the same name, is at version Y? This would lead to grossness such as "libcups2-1.4.4". It is version2, but it is version 1.4.4? This is confusing to a user, who at first glance (being used to our release of things like "mysql4" vs "mysql5" packages, may think, "oh, there's a version 2 of libcups" when there is not.

Perhaps the foo.so.N+1 is an unfortunate case when the major software
version is N.  If you saw, say, libcups3, you wouldn't think it's the
version 3 of cups as there's no version 2 of cups yet.

While this could in fact be somewhat confusing to a user, I think it's
very unlikely that it would.  The libcups2 package is only a shared
library, and will probably never be installed by itself.  The typical
two cases are installing cups itself, or installing cupsdevel to
compile other software with cups support.  As Sebastian has said
before, it's unlikely any user would care about lib packages.

To answer the main question about libFoo at version X with library at
version Y -- the answer is that you follow the recommendation.
Assuming you care about capitalization:

CSWlibFoo contains everything minus devel, minus shared libs, etc,
potentially unnecessary
CSWlibFoo-devel with headers
CSWlibfooY with the shared library (library package names are
normalized with lowercase)

> In these cases, perhaps it is better to encode the SONAME version information somewhere other than immediately after the softwarename. Perhaps libcups-1.4.4_so2,REV=2010.xx.xx? similarly, libcupsimage-1.4.4_so2,REV=2010.xx.xx? libcupsimage-1.4.4,so=2,REV=2010.xx.xx
> Hmm. except that would not allow for specific version-based dependencies. So libcupsimage_so2-1.4.4, libcups_so2-1.4.4 ?

We try to keep package names short, and the "_so" bit would be
repetitive and not very helpful in most cases, but it's a possibility.

WRT grouping libraries - yes, you are right that what matters here is
whether libraries change together.  Matching library versions is only
a heuristic.  We can emphasize this in the document if you want to.
We can also replace this heuristic with something else, but we need a
way to decide, given a set of sonames, whether they belong together or
not.  As Debian policy points out, it's always safe to split libraries
to separate packages, and I think it's reasonable to nudge the
maintainer about non-version-matching sonames in one package.

I'm not pushing towards this being a policy; it can remain a best
practices recommendation.  I wouldn't mind it becoming the policy, but
I understand that there is already a large number of packages, and not
everybody will be happy to rework all their packages.  What I would
like to achieve is that if a maintainer submits a package following
this recommendation, the package is not rejected on the grounds of
doing so.

What do you intend to do with your comments in on the wiki page?  I
guess we want to arrive at a clean version of the document that can
eventually become our recommendation.