[pacman-dev] [PATCH] makepkg: allow compression type to be autodetected

[Dan McGee]

On Fri, Sep 5, 2008 at 6:25 AM, Teran McKinney <sega01 at gmail.com> wrote:
> Wouldn't this break package extensions that are not *.tar.{gz,bz2}? I
Yes- partially. It will no longer compress them and will simply tar
them. Probably not what you intended.

> personally do not like this, as my Arch fork uses .ipkg (I find
> pkg.tar.$COMPRESSION very ugly, IMHO). Perhaps tar could simply tar
> the archive and a setting in makepkg.conf would allow for any method
> of compression? Example:
We just eliminated a whole bunch of this crud because it was unused
and not worth it- it made so much more sense to autodetect.

The one valid case I can see here is defaulting to gzip if no
compression method was specified, rather than falling back to an
uncompressed tar file.

> makepkg.conf:
> COMPRESS='gzip -9'
>
> Makepkg:
> bsdtar -cf "$pkg_file" $comp_files *
> $COMPRESS "$pkg_file"
>
> Of course, you would need to deal with renaming it from
> ${EXTENSION}.gz back to $EXTENSION. Some error checking would be nice
> too.

So now we've turned a one step process into two and added the need to
error check. Seems like it just got way more complex than necessary.

> Regarding repo-add, it could simply `tar -xf` and it would be
> extracted if `tar` understands that type of compression. It could also
> check with `file`, perhaps.

Um, this has been the case for ages- we just recently got smart and
actually re-compressed it in the "right" format, however. bsdtar does
transparent decompression. What you are proposing (I think) is rather
than key off the DB extension for the *re-compression* that needs to
occur, key off the original archive format? The issue here is that
creating a new DB would then be a special case, so what format would
we use for that?

> PS: Why is bsdtar used instead of GNU tar?
bsdtar is shipped with libarchive, which libalpm depends on so we know
will be installed on systems. In addition, it is faster, regularly
updated, and a pretty good product.

Sorry for sounding overly combative here, but your points just have a
ton of issues that may not have been immediately obvious, and I wanted
to make sure it was obvious why I settled on the solution I did.

-Dan