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 firstname.lastname@example.org Debian Developer
Description: This is a digitally signed message part.