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

[Benjamin Seidenberg]

I have gotten in touch with the Easyh10 author (he was on vacation)
and cc'd my reply (including his email) to this list. He had not yet
approached  upstream, and will do so when he finishes his vacation.
Nyaochi: Please keep pkg-mad-maintainers at lists.alioth.org in the CC of
our messages so they can keep up to date.

Thanks!
Benjamin

On 8/20/05, Sam Clegg <sam at superduper.net> wrote:
> 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 $
> 
> 
> 
>