Re: [Mingw-cross-env-list] call for testing: support for lzma archives

[Volker Grabsch]

Tony Theodore <address@hidden> schrieb:
> On 14 September 2010 06:42, Mark Brand <address@hidden> wrote:
> >
> > Thanks for checking that out. It looks like a safe choice is  "| tar xf -",
> > although I even considered "| tar xf /dev/stdin"!
> >
> > http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/eebfbf8cbcda
> 
> Seems like the path of least resistance, however, if we made a
> "modern" tar one of the requirements, we could use the auto-detection
> and extract most formats with the tar xf $(1) syntax.

That would be really great, but I think we should wait with that
until such a recent tar version appears at least in Debian/Stable.

(.. and in the other systems, too, but that's usually the case when
something gets finally into Debian/Stable ;-))

> If we used libarchive (bsdtar), we could also get rid of the UnZip
> requirement since it can extract these also.

I have no objections with replacing GNU Tar + Unzip with BSD Tar,
as long as there are binaries for all distros mentioned in our
"requirements" section. (see below)

> We could take it one step further and build a libarchive-native
> ourselves. It could install itself as $(TARGET)-tar (or something
> similar), then we have:
> 
> TAR = $(shell $(TARGET)-tar --help >/dev/null 2>&1 && echo $(TARGET)-)tar
> 
> that re-evaluates itself for each pkg, and
> 
> UNPACK_ARCHIVE = $(TAR) xf '$(1)'

I think this is going a little bit too far. :-)

We would introduce a new package build just to save 3 trivial lines
in the UNPACK_ARCHIVE macro. (see below for more information)

> The main problem with this is that it assumes the new native tar will
> be built very early in the dependency chain. We could avoid that by
> keeping UNPACK_ARCHIVE much the same and only using the new native tar
> for *.lzma and *.zip files. In that case, we don't need the TAR
> variable, just $(TARGET)-tar xf $(1) on the respective lines in
> UNPACK_ARCHIVE. We'd still need to ensure that the first (or every)
> pkg that uses these formats has the dependency specified (it's only
> coincidental that w32api is very early).
> 
> What do you think? It reduces requirements (xz, unzip) and increases
> complexity a little.

Our current strategy is quite the reverse, and I'd like to stick with
it as it served us quite well up to now.

That is, unless there's some good reason to build a package on our own
we should either add it to the dependencies, or avoid the dependency
alltogether.

With "good reason" I mean something like cross compilers, binutils,
code generators that must belong to a certain version of a library,
or tools that aren't available as ready-to-use packages in the bigger
distros (e.g. NSIS).


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR