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

On Fri, Sep 5, 2008 at 6:25 AM, Teran McKinney wrote: 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

On Fri, Sep 5, 2008 at 1:03 AM, Xavier wrote:

On Fri, Sep 5, 2008 at 3:46 AM, Dan McGee wrote:

...

Inspired by commit 7e8f1469c4168875b54956d63884b8583ce99e38, use our given PKGEXT or SRCEXT to determine what method of compression to use on the package we create. If the extension is invalid, this should fall back to creating a non-compressed tar file.

Signed-off-by: Dan McGee

Looks nice, and repo-add and pacman could already handle tar.gz and tar.bz2 transparently.

I forgot a note saying this was completely untested. We will want to obviously run it through its paces if possible. -Dan