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 <[EMAIL PROTECTED]> 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) [EMAIL PROTECTED] "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/ -----------------------------------------------------------
pgpMYbTezkq5S.pgp
Description: PGP signature
