[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Reopening Bug#267042, libptp2 and a lintian warning.

On Sat, Oct 01, 2005 at 09:56:16AM +0200, Antonio Ospite wrote:
> On Fri, 30 Sep 2005 23:15:44 +1000
> Paul TBBle Hampson <Paul.Hampson@anu.edu.au> wrote:

>> On Fri, Sep 30, 2005 at 12:00:43PM +0200, Antonio Ospite wrote:
> >> There is an issue with the package name, lintian says:

> >> W: libptp2: package-name-doesnt-match-sonames libptp2-1

> >> but libptp2 is not intended to be the second version of libptp, it
> >> is a different thing and so I (and the upstream author) think that
> >> the package should be named libptp2 and not libptp2-SONAMEVERSION
> >> as the library policy would suggest. May I override the lintian
> >> warning about this issue?

>> sonames go in the library package name so that different versions of
>> the library with the same name but different soversions are parallel-
>> installable.

>> libptp2, which you've suggested, is libptp soversion 2. What you said
>> you want is what lintian suggests, libptp2 soversion 1: "libptp2-1"

> well, actually libptp2 is libptp2 soversion 1, the shared object file
> is named libptp2.so.1.

Not according to Debian's library naming policy. Calling it libptp2
produces an expectation that the package will contain
/usr/lib/libptp.so.2.x.y and a symlink from /usr/lib/libptp.so.2, and
that any program that works with libptp2 will work with any future
libptp2. If upstream promises to _never_ _never_ _never_ remove or
change any symbols, but only add new ones, an exception might be made.
And it'll have to survive both debian-devel (where you'll be told all
this again, but with more force and possibly some direct personal abuse)
and ftp-masters.

> The upstream asked me to call the package libptp2 and not libptp2-1,
> should I follow his request?

Not where it conflicts with Debian packaging policy, no.

If upstream doesn't like this, point out that there's no libmysqlclient
in Debian either. I think upstream is confused about what they want from
a Debian package name. The _source_ package name would make sense as
libptp2, but there'll be no binary package by that name.

>> This means you'll get libptp2-dev and libptp2-bin (if you need a -bin)
>> associated packages.

> I don't understand here; if the package is called libptp2-1, hasn't the
> dev package to be named libptp2-1-dev ?

Not neccessarily. The -dev package is generally libraryname-dev, unless
there is a good reason to have different -dev pacakges parallel
installable for the different soversions... libmysqlclient for example
does this, I think partly because the license change between sovers 10
and 12 meant that people needed to be able to link against whichever
version was acceptable but mainly because it's such a commonly-linked
library and is not symbol-versioned, you need to be careful not to have
one program ultimately linked against two different sovers of it.

This is prolly a good point to prompt your upstream about symbol
versioning. ^_^

Another reason to use libptp2-1-dev is if upstream tends to change the
API non-backwards-compatibly. This way working packages won't be broken
by a new upload by you. This is done by gtk, for example, who put the
API into the package name. The 1.2 series has also gotten by on having
no soversion in the package name, because they have made the
abovementioned promise to not break backwards compatibility. The 2.0
series of GTK however uses the standard soname versioning, although
they're still on -0 so they've yet to need it. ^_^

If upstream is inclined to break API like this, suggest that when they
do so that they call it libptp3 instead. ^_^

Keep in mind that having a libptp2-1-dev and a libptp2-2-dev will need
to come from seperate source packages or updating libptp2-1-dev will be
impossible once libptp2-2-dev hits the archive. And you really don't
want to be responsible for something in the archive becoming
non-updatable. libmysqlclient for example has the .so.10 version as its
own source package (no one wanted to keep mysql3 itself in the system,
and mysql3 had the same source package name as mysql 4.0 "mysql-dfsg")
while all later versions come from a mysql-dfsg-4.x source package, so
can be updated in parallel. However, this is hard work. You don't want
to choose to do it lightly.

If you go the libptp2-1-dev route, consider having libptp2-1-dev provide
and conflict with libptpt2-dev for people who want to develop against
libptp2 to be able to find the current -dev package easily. There was a
discussion on debian-devel a month or two ago about soversions and API
versions you may want to read, but I think the above summarises the
ultimate outcome. Either way, packages still should refer to the
specific sover -dev package if it exists, under the assumption that the
packager of the library knows what they're doing. ^_^

Otherwise having only a libptp2-dev means packages will pick up a new
soname of the package with only a rebuild, not needing the
debian/control file edited. Mind you, a time-delayed autobuild may
produce soname skew across architectures.

This choice is a bit of a judgement call about the way the library will
change in the future. So it's hard. ^_^

No matter how you do -dev, you'll not want to have libptp2-1-bin unless
you can make a strong case that there needs to be the support binaries
for _both_ versions installable simultaneously. And then you may have to
weather the whole 'circular depends' issue, another source of pain and
anguish. _And_ find a good home for them, and a good way of getting to
them both. An example of this area is postgresql, as it needs old
binaries available to upgrade databases. However, the old binaries
aren't available in the path, so there's no need to worry about
accidentally running the wrong one.

Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

License: http://creativecommons.org/licenses/by/2.1/au/

Attachment: pgpcy5GUz8DoG.pgp
Description: PGP signature

Reply to: