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?
- 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
Attachment:
signature.asc
Description: This is a digitally signed message part.