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

Re: Suggestion to remove (eventually) libtar from Debian



Magnus Holmgren <holmgren@debian.org> writes:

> libtar popped up on wnpp-alert, so I ITAd it, but now I'm having second 
> thoughts. I've done one upload now though.
>
> - No new releases since 2003. Upstream hasn't bothered building a dynamic 
> library, that's a Debian patch (and a corresponding patch in other distros).
>
> - libarchive is superior (I suppose).
>
> - The API has some problems: th_get_pathname() sometimes returns a pointer 
> into the TAR struct passed to it and sometimes a pointer to malloc()ed memory 
> (a strdup() of a local buffer). It has been suggested to always strdup() the 
> result instead, but it's also been suggested to return a pointer to a static 
> buffer in applicable cases, which I think may be better (you have to copy the 
> returned string anyway since the TAR struct is updated as you iterate over the 
> tar contents). Thoughts?

Thread safety and rentrancy is a problem there.

A third option is to pass a buffer to the function (plus its size) and
fill it with the name. I would probide both a strdup() and a buffer
passing version of the function so people can choose.

> - Another problem is the tartype_t struct that you can pass to tar_open() to 
> provide your own functions for opening, reading and writing the underlying 
> file, e.g. to handle compressed tar files. Unfortunately you have to put your 
> context in an int instead of a more versatile void*.
>
> - It is riddled with MAXPATHLEN, so getting it to build on HURD doesn't seem 
> worthwile.
>
> - It has few rdepends:
>   barry - uses th_get_pathname() (with the comment "FIXME (leak) - someday,
>           when all distros use a patched version of libtar, we may be able to
>           avoid this memory leak, but th_get_pathname() does not consistently
>           return a user-freeable string on all distros."
>   composite - already supports libarchive, it seems.
>   lordsawar - Not sure about this one.
>   osmo  - Uses libtar very simply to make and restore backups. Should be easy
>           to convert to libarchive.
>   stopmotion - Not sure about this one.
>   vlc   - The skins2 UI module uses libtar to unpack skins. Should be easy
>           to convert to libarchive.
>
> Any thoughts?
>
> -- 
> Magnus Holmgren        holmgren@debian.org
> Debian Developer 

I guess the maintainers of the rdepends should make the choice (and do
the work :).

MfG
        Goswin


Reply to: