[pkg-mad-maintainers] Patch to libid3tag0-dev for EasyH10

Sam Clegg sam at superduper.net
Sat Aug 20 11:20:34 UTC 2005


Kurt Roeckx wrote:
> On Sat, Aug 13, 2005 at 09:03:12PM +0200, Clément Stenac wrote:
> 
>>Hello,
>>
>>This is of course always possible but requires to modify the SONAME of
>>the library, which will not match the upstream anymore. This is
>>acceptable, but not really recommended.
> 
> 
> Actually, just adding function doesn't require an soname change,
> this is a backward comptabible API/ABI change, and just requires
> us to bump the shlibs.
> 
> But I agree that we should try to get it merged upstream.
> 
> Also, it would be nice to know what the intended use of those 3
> added functions are, maybe we can come up with a better/more
> general solution to the problem, or some better way to do it.
> 
> It contains this change:
> -  file->path    = path ? strdup(path) : 0;
> +  if (path) {
> +         file->path = (char *)malloc(strlen(path)+1);
> +         strcpy(file->path, path);
> +  } else {
> +         file->path = 0;
> +  }
> 
> I don't see why this is changed, both really should do the same.


Aggreed.  This part look pointless.

The following part means that if there is a problem parsing and Id3
frame the library will return you just the frames it could parse.  I'm
not sure if this is what we want.

--- libid3tag-0.15.1b/tag.c>----2004-02-17 01:04:10.000000000 +0000
+++ libid3tag-0.15.1b_easyh10-0.10/tag.c>-------2005-06-05
03:33:58.000000000 +0100
@@ -605,8 +605,17 @@
 >------break;  /* padding */
-
       frame = id3_frame_parse(&ptr, end - ptr, tag->version);
-      if (frame == 0 || id3_tag_attachframe(tag, frame) == -1)
->------goto fail;
+>------  /* Recover from error. */
+>------  if (frame) {
+>------>-------if (id3_tag_attachframe(tag, frame) == -1) {
+>------>-------  goto fail;
+>------>-------}
+>------  } else {
+>------>-------if (tag->nframes == 0) {
+>------>-------  goto fail;
+>------>-------}
+>------>-------break;
+>------  }
     }


The rest of the parch adds id3_file_content_offset, id3_file_gettag,
and id3_file_getnumtag.  I'm not sure about these either.  IIRC the
id3_file interface is designed to be a simple way to get a tag out of
a file.  If you want these extra functions you can use the id3_tag
interface which will tell you the size of any tags.

Having said that I don't see a problem with adding these features.
Whats the debian policy on adding features?   Also, lets at least
wait to hear from upstream.


-- 
sam clegg
:: sam at superduper.net :: http://superduper.net/ :: PGP : D91EE369
$superduper: .signature,v 1.14 2005/01/19 13:21:14 sam Exp $

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-mad-maintainers/attachments/20050820/de52950a/signature.pgp


More information about the pkg-mad-maintainers mailing list