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

Re: Advice on packaging libmusicbrainz4



On Wed, Mar 14, 2012 at 03:41:50PM +0000, Andy Hawkins wrote:
> Hi all,
> 
> I am the author of libmusicbrainz4, a library to access the MusicBrainz
> service. There have been previous versions of this library in Debian, and I
> would like to get this new version included if at all possible.
> 
> A couple of questions:
> 
> 1. There already appears to be a libmusicbrainz4 package
> (libmusicbrainz4-dev and libmusicbrainz4c2a), based on v2.1.5 of the
> libraries. I can't understand why these were named 'libmusicbrainz4', but
> obviously this will clash with the package name I'd ideally like to use. I
> did consider 'libmusicbrainz4-ngs' as this library is aimed at accessing the
> 'Next Generation Schema' on the Musicbrainz site. Would appreciate any
> comments.

The "4" in those packages comes from the major version number in the library's
SONAME, "libmusicbrainz.so.4".  The new version you are looking at packaging is
a little trickier, because it has a number in the library's name itself in
addition to the SONAME version: "libmusicbrainz4.so.3".  Following the normal
conventions, you'd prepare a source package named libmusicbrainz4, creating
binary packages libmusicbrainz4-3 and libmusicbrainz4-dev.  However, since the
-dev package name is already taken (it probably should have been simply
libmusicbrainz-dev), that's obviously a problem....  You might try a name like
libmusicbrainz4-ngs-dev, which is ugly, but at least it's nonconflicting.

Does the old library still function with the MusicBrainz service?  If it's just
deadweight now, you could also work to transition all packages still using the
old library (there are four) to the new, request the removal of the old
library, and then eventually take over the libmusicbrainz4-dev package name.

> 2. The source for the library automatically generates a couple of files
> *into the source directories*. As a result of this, the 'diff' that is
> created for the debian files (incorrectly) contains these files. Can you
> tell me how I would exclude these files from this diff?

Autogenerated files should be removed in the "debian/rules clean" target.  It's
your choice whether you'd rather implement it there, or in the library's own
"make clean" routine.


-- 
Nicholas Breen
nbreen@debian.org


Reply to: