What to do about the situation with id3v2
Hello my fellow maintainers and DDs
I have a question concerning two of my packages: I am maintaining
id3v2 [1] and libid3 [2]. For those unfamiliar with them, id3v2 is a
simple command-line tool to manage ID3 tags and libid3 is the library
behind it. Now, those packages suffer from some major issues:
- The library (and thus the tool) cannot handle version 2.4 ID3 tags
(they only support version 2.3 of the standard - a rather outdated
version).
- Partly as a consequence of the lack of v2.4 support, Unicode tags
are broken. Most of the remaining bug reports are related to this [3]
[4].
- Upstream development for both packages is pretty much dead.
When I originally adapted the packages, my intention was to fix this -
so far I failed miserably, partly because I'm not sure how to approach
the problem. My current ideas are:
- Port id3v2 to libid3tag [5]. This is a different id3 tagging library
which supports v2.4 tags. I did some work in this direction but I
realized that this would require major modifications to id3v2 since
it's closely modeled around libid3. Also, some modifications to
libid3tag would be required to support all the current features of the
id3v2 program. My current estimate is that the work required for a
complete port of id3v2 would be close to rewriting it from scratch and
would result in a program that hardly shares any code with the current
id3v2 tool.
- Fix libid3 to support v2.4 tags and Unicode. This would probably
only require minor changes to id3v2, but it would introduce a
significant delta between the Debian version of libid3 and upstream,
making me the de-facto upstream for the library. Also, this would mean
a lot of work to basically duplicate the "other" id3 tag library
(libid3tag).
- Drop id3v2 and replace it with a wrapper around one of the other
command-line id3 taggers. This would however leave the "broken"
library in the repository since other packages also use it. Also, I
haven't actually investigated the alternatives. One possibly
interesting candidate is eyed3 [6] but since this is a python
application, that would introduce a whole lot of new dependencies for
the users of id3v2.
My personal goal for wheezy is to fix this mess, but since none of the
solutions I can currently think of convince me, I'd like to get some
input from other package maintainers. What would you do in a similar
situation? Do you have other ideas than the ones mentioned above? Any
input would be highly appreciated.
[1] http://packages.debian.org/sid/id3v2
[2] http://packages.debian.org/sid/libid3-3.8.3-dev
[3] http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=id3v2;dist=unstable
[4] http://bugs.debian.org/cgi-bin/pkgreport.cgi?ordering=normal;archive=0;src=id3lib3.8.3;dist=unstable;repeatmerged=0
[5] http://packages.debian.org/sid/libid3tag0
[6] http://packages.debian.org/sid/eyed3
cheers
--
Stefan Ott
http://www.ott.net/
"You are not Grey Squirrel?"
Reply to: