Hi,
In article <20120315002612.gm15...@ofb.net>,
Nicholas Breen<nbr...@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
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/slrnjm4122.dsl.a...@atom.gently.org.uk
