[csw-pkgsubmissions] newpkgs cups

[Maciej (Matchek) Blizinski]

[+maintainers, bcc:pkgsubmissions]

Link back to the start of the thread on pkgsubmissions:
http://lists.opencsw.org/pipermail/pkgsubmissions/2010-November/001528.html

No dia 9 de Novembro de 2010 16:47, Philip Brown <phil at bolthole.com> escreveu:
> On 11/9/10, Maciej (Matchek) Blizinski <maciej at opencsw.org> wrote:
>> No dia 8 de Novembro de 2010 20:10, Philip Brown <phil at bolthole.com>
>> escreveu:
>>>
>>> bug #2: erm... so how come something named "libcups **2**", has
>>> version=1.4.4  ?
>>> that's very confusing.
>>
>> It's the same naming scheme as with every other shared library.  If
>> you look at the soname, it's libcups.so.2, which gives us CSWlibcups2.
>>  It has been built from cups sources version 1.4.4, and hence the
>> version.
>>
>
> I dont think "the same as every other shared library" quite fits,
> here. There are many libxxx packages that do not fit that naming
> scheme.
> I'm thinking this is the "new" library naming scheme you proposed, yes?

Yes, that's it.

> Do we have the specifics of the proposal up somewhere, either  on main
> site, or on wiki?

There is a best practices writeup on the wiki, on the checkpkg error
tags page, about the shared-lib-pkgname-mismatch tag.  It links to the
original discussion on the mailing list; the rationale is written up
in the first post.  There's also a link to a file with unit tests and
examples of 12 different sonames and resulting package names.

http://wiki.opencsw.org/checkpkg-error-tags#toc5

> Although your libpython seems relatively fine.
> your libcups2 package does not match that. oh wait, it sort of does...
> this is a single-digit-rev shared lib.
> Which fits my original addendum to the proposal, if I recall:
> "[libraries with single-digit (version numbers in the file) do not
> usually need to be split out"
>
> This would seem to be the case for cups, where the SONAME has not
> changed in over 3 years.

I don't think your proposed addendum got accepted, did it?  I have
discussed this and explained why the number of elements in the soname
version does not affect the shared library life cycle.  Here's the
reference:

http://lists.opencsw.org/pipermail/maintainers/2010-October/012850.html

> using our existing defacto standards of naming, having
>
> softname
>  and
> softname2
>
> usually means two separate, different-by-major-number versions of the software.
> So libcups2 is confusing.

What do you mean by confusing - what else do you think it could be?

Let's consider a hypothetical release of cups version 2, which could
be installed together with cups 1.x (regardless of how much sense it
could have).  I think this is the scenario you had in mind. Cups
version two would probably increment the soname version of libcups, or
change the soname altogether.  Distributed files would be
libcups.so.3, or libcups2.so.1 (or similar).  Here's a rundown of
hypothetical sonames of cups2 and resulting package names:

example 1: libcups.so.3 - CSWlibcups3
example 2: libcups2.so.1 - CSWlibcups2-1
example 3: libcups2.so.2 - CSWlibcups2-2
example 4: libcups2.so - CSWlibcups2

Only the example 4 could be ambiguous; but changing the soname from
libcups.so.2 to libcups2.so would be an evil thing to do, and I don't
think cups developers would ever change the soname that way.  I doubt
that it was the scenario you had in mind.  Barring the hypothetical
libcups2.so example, the CSWlibcups2 package name is unique and
explicit.

Here's an important note on package names:

The package names (pkgname and catalogname) depend solely (!) on
sonames.  They explicitly do not depend on project names, or sources
versions.  CSWlibcups2 is named the way it is because it contains
libcups.so.2.  The "cups" word is there just by coincidence - it so
happens that the project name is embedded in the soname.  Does this
explanation make it more clear to you?

> softname2_x_y  is a bit more indicative of the sharedlib scheme you've proposed.
> Perhaps the proposal needs something a bit more explicit to denote
> "this is a split-off shared lib", since we've found a case where
> having a leading "lib" is not sufficient to denote that any more.

Do you mean some kind of naming prefix unambiguously identifying
packages with shared libraries?  What would be its purpose?  The core
of the package naming policy is that every soname has its own pkgname
and catalogname.  It's not about a perfect mapping from pkgnames to
shared library names, or about identifying packages with shared
libraries just by package names.  The purpose of the soname-driven
naming is to facilitate a healthy shared library life cycle.