Re: Advice on packaging libmusicbrainz4

[Andy Hawkins <andy@gently.org.uk>]

Hi,

In article <[🔎] 20120315002612.GM15420@ofb.net>,
           Nicholas Breen<nbreen@debian.org> wrote:
> 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.

That name was exactly what I'm using with my test packages currently
(libmusicbrainz4-ngs and libmusicbrainz4-ngs-dev).

> 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.

I have no idea if the old library works with the existing service. I don't
really want to get into the hassles of changing other packages to work with
libmb4. It's a significant change over previous versions of the library
(libmusicbrainz3 is the most recent).

> 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.

Ah, hadn't realised that. It could be a deficiency in my 'clean' target
then. I'll look into that.

Thanks

Andy