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

Re: Bug#669373: RFS: flactag/2.0.1-1 ITP #507876




On 19/04/12 20:41, Nicholas Breen wrote:
> On Thu, Apr 19, 2012 at 03:07:51PM +0200, Daniel Pocock wrote:
>>     flactag    - Tagger for whole-album FLAC files using data from
>> MusicBrainz
> 
> This is closing a fairly old (2008) ITP, so it might be good to re-evaluate
> other software in the same space that is in Debian now -- particularly beets,
> which appears to be very similar (also a CLI-interface, MusicBrainz-backed,
> album-oriented tagger but supports formats besides FLAC).  If you think
> flactag's different enough, please highlight some of its unique features in the
> long description so users can choose the program that best suits them.

I just had a quick look at beets description.  I think the fact that
beets is python and flactag+libmusicbrainz4 is C++ is a sufficient
reason to have both in Debian.

A second reason is that flactag is more lightweight: it doesn't try to
be an all-in-one solution.  Some people may prefer having separate tools
to accomplish tasks that don't fit within the workflow of a solution
like beets.

> Separately, please do not Build-Depend on libjpeg62-dev, as it's being removed.
> See #547393.

It does still appear in wheezy...

http://packages.debian.org/search?keywords=libjpeg62-dev

but we'll get rid of that dependency.  If I understand correctly,
flactag should depend on libjpeg8 (and not libjpeg7?)

http://packages.debian.org/search?keywords=libjpeg8

>>     dget -x
>> http://mentors.debian.net/debian/pool/main/libm/libmusicbrainz/libmusicbrainz_4.0.1-1.dsc
> 
> As you know, there's already a binary package "libmusicbrainz4-dev" in the
> archive, which Timo has been working on removing (thanks!).  However, this new
> package still couldn't go in until the old one is removed.

Given that the musicbrainz public API (as exposed from their internet
server) has changed so dramatically, the old musicbrainz packages really
do have to go, so this shouldn't be an issue?  Is there any delay/lead
time we should anticipate to purge the old package?


Reply to: