All of lore.kernel.org
 help / color / mirror / Atom feed
* [RFC] pack/unpack: generic archive creation and extraction utilities
@ 2026-08-13 14:45 Iván Ezequiel Rodriguez
  2026-08-13 16:09 ` Chris Hofstaedtler
  0 siblings, 1 reply; 2+ messages in thread
From: Iván Ezequiel Rodriguez @ 2026-08-13 14:45 UTC (permalink / raw)
  To: util-linux

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [RFC] pack/unpack: generic archive creation and extraction utilities
  2026-08-13 14:45 [RFC] pack/unpack: generic archive creation and extraction utilities Iván Ezequiel Rodriguez
@ 2026-08-13 16:09 ` Chris Hofstaedtler
  0 siblings, 0 replies; 2+ messages in thread
From: Chris Hofstaedtler @ 2026-08-13 16:09 UTC (permalink / raw)
  To: Iván Ezequiel Rodriguez; +Cc: util-linux

* Iván Ezequiel Rodriguez <ivanrwcm25@gmail.com> [260813 16:45]:
>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.

Purely with my Debian hat on: please put this either into libarchive 
or just a new tool. Adding a dependency from util-linux to 
libarchive is (from my PoV) not a great idea, especially when the 
tools can easily live in another place.

IIRC libarchive's "tar" can already unpack zips and so on...

Best,
Chris


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2026-08-13 16:09 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-08-13 14:45 [RFC] pack/unpack: generic archive creation and extraction utilities Iván Ezequiel Rodriguez
2026-08-13 16:09 ` Chris Hofstaedtler

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.