[gentoo-pms] *.tar.lzma is not mentioned

[gentoo-pms] *.tar.lzma is not mentioned

[Ulrich Mueller]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 376 bytes --]

PMS doesn't mention lzma-compressed tar files, but Portage (and also
Paludis, as far as I can see) can unpack them.

And I think calling simple *.lzma and *.xz files "archives" is
misleading. They are just single compressed files like *.gz or *.bz2.
Patch is attached.

We could also think about reordering the list of extensions. Currently
it's not very systematic.

Ulrich


[-- Attachment #2: 0001-Mention-lzma-compressed-tar-files.-Clarify-wording-f.patch --]
[-- Type: text/plain, Size: 2003 bytes --]

From 9254c33ae5ed872b84a57c72a250a90d3b5c33ff Mon Sep 17 00:00:00 2001
From: Ulrich Mueller <ulm@gentoo.org>
Date: Sat, 27 Jun 2009 23:18:13 +0200
Subject: [PATCH] Mention lzma-compressed tar files. Clarify wording for lzma and xz.


Signed-off-by: Ulrich Mueller <ulm@gentoo.org>
---
 pkg-mgr-commands.tex |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/pkg-mgr-commands.tex b/pkg-mgr-commands.tex
index 1403cd1..16084e2 100644
--- a/pkg-mgr-commands.tex
+++ b/pkg-mgr-commands.tex
@@ -767,11 +767,13 @@ has returned.
     \item LHA archives (\t{*.LHA, *.LHa, *.lha, *.lhz}). Ebuilds must ensure that the lha program is
     installed.
     \item ar archives (\t{*.a, *.deb}). Ebuilds must ensure that GNU binutils is installed.
-    \item lzma archives (\t{*.lzma}). Ebuilds must ensure that LZMA Utils is installed.
-    \item xz archives (\t{*.xz}). Ebuilds must ensure that XZ Utils is installed. Only for EAPIs
-        listed in table~\ref{tab:unpack-extensions-table} as supporting xz.
-    \item xz-compressed tar files (\t{*.tar.xz}). Ebuilds must ensure that XZ Utils is installed.
-        Only for EAPIs listed in table~\ref{tab:unpack-extensions-table} as supporting xz.
+    \item lzma-compressed files (\t{*.lzma}). Ebuilds must ensure that LZMA Utils is installed.
+    \item lzma-compressed tar files (\t{*.tar.lzma}). Ebuilds must ensure that LZMA Utils and
+    GNU tar are installed.
+    \item xz-compressed files (\t{*.xz}). Ebuilds must ensure that XZ Utils is installed. Only for
+    EAPIs listed in table~\ref{tab:unpack-extensions-table} as supporting xz.
+    \item xz-compressed tar files (\t{*.tar.xz}). Ebuilds must ensure that XZ Utils and GNU tar are
+    installed. Only for EAPIs listed in table~\ref{tab:unpack-extensions-table} as supporting xz.
     \end{itemize}
     It is up to the ebuild to ensure that the relevant external utilities are available, whether by
     being in the system set or via dependencies.
-- 
1.6.3.1

Re: [gentoo-pms] *.tar.lzma is not mentioned

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1417 bytes --]

On Sat, 27 Jun 2009 23:33:33 +0200
Ulrich Mueller <ulm@gentoo.org> wrote:
> PMS doesn't mention lzma-compressed tar files, but Portage (and also
> Paludis, as far as I can see) can unpack them.
> 
> And I think calling simple *.lzma and *.xz files "archives" is
> misleading. They are just single compressed files like *.gz or *.bz2.
> Patch is attached.

Applied, thanks (I tweaked the indenting slightly).

> We could also think about reordering the list of extensions. Currently
> it's not very systematic.

Right. I think the order's how things used to be in Portage back when
we made the list. It'd probably look nicer as a table, something like:

    Extension     EAPIs          Must have installed
                  1 2 3
    .tar.gz       y y y          GNU tar, GNU gzip
    .tar.lzma         y          LZMA Utils

That's an 'easy' exercise for someone who feels like being helpful...

Incidentally, one of the things I was hoping to get in for EAPI 4 was a
fix for the arbitrary and weird dependencies required for unpacking. I
think we briefly discussed doing something like making the package
manager have 'magic' packages, so you'd do:

    DEPEND="package-manager-magic/unpack-zip"

to tell the package manager to depend upon whatever it really uses to
unzip things. I don't recall whether this was feasible from a Portage
perspective though.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]