From: "Iván Ezequiel Rodriguez" <ivanrwcm25@gmail.com>
To: util-linux@vger.kernel.org
Subject: [RFC] pack/unpack: generic archive creation and extraction utilities
Date: Thu, 13 Aug 2026 11:45:35 -0300 [thread overview]
Message-ID: <20260813144535.79126-1-ivanrwcm25@gmail.com> (raw)
Hi,
I'd like to ask whether two small archive-oriented commands, pack and
unpack, would be considered within the scope of util-linux.
The idea is a simple interface for a common operation that currently
requires knowing the particular archive/compression tool and its syntax:
pack FORMAT SOURCE...
unpack ARCHIVE
For example:
pack tar.zst src/
pack zip file1 file2 dir/
unpack archive.tar.zst
unpack archive.zip
pack requires the output representation to be selected explicitly,
while unpack detects the existing representation automatically.
The intention is not to replace tar, gzip, xz, 7z, etc., nor to
expose all of their specialized functionality. It is to provide a
small generic interface for the basic "pack these files" / "give me
back these files" operations.
I first asked on the GNU coreutils list:
https://lists.gnu.org/archive/html/coreutils/2026-08/msg00027.html
Pádraig Brady replied that the functionality is useful (he had
previously used atool for this). He was not convinced coreutils is
the right home, suggested util-linux as one possible fit (noting it
has general non-Linux-specific tools despite the name), and also
suggested investigating whether pack/unpack might belong in
libarchive alongside bsdtar.
I am writing here to ask if util-linux would consider
commands with this scope in principle.
I have a working reference implementation in C (current tip v1.6.1):
https://github.com/IRodriguez13/pack-unpack
The implementation uses libarchive rather than implementing archive
formats itself. It currently supports tar and compressed tar variants,
zip, 7z, and several raw compression formats.
Some properties of the current code:
- silent successful operation, with -v for member listing;
- relative archive member names;
- atomic archive creation using a temporary file and rename;
- defensive extraction against absolute paths, "..", and
symlink/hardlink escapes;
- explicit overwrite policies;
- conservative metadata restoration by default, with -p for
additional metadata;
- regression tests for malformed and hostile archives;
- CI on GNU/Linux (glibc and musl), FreeBSD, and macOS,
including ASan/UBSan testing.
The reference tree is GPLv3+ today. I am the copyright holder and am
willing to relicense those sources under GPL-2.0-or-later (util-linux's
default) if the concept is of interest.
I realize an optional libarchive dependency may itself be an important
consideration, so feedback on whether that would be a fundamental
obstacle would also be very welcome.
Before attempting to adapt anything to util-linux conventions or
preparing patches, I'd like to know whether commands with this scope
are something the project would consider in principle.
Feedback on the interface, scope, naming, or whether this belongs
elsewhere would be very welcome.
Thanks,
Iván Ezequiel Rodriguez
ivanrwcm25@gmail.com
https://github.com/IRodriguez13/pack-unpack
next reply other threads:[~2026-08-13 14:45 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 14:45 Iván Ezequiel Rodriguez [this message]
2026-08-13 16:09 ` [RFC] pack/unpack: generic archive creation and extraction utilities Chris Hofstaedtler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260813144535.79126-1-ivanrwcm25@gmail.com \
--to=ivanrwcm25@gmail.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox