Gentoo Archives: gentoo-portage-dev

From: "Michał Górny" <mgorny@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] Re: [RFC] gpkg format proposal v2
Date: Mon, 12 Nov 2018 21:29:37
Message-Id: 1542058170.32428.12.camel@gentoo.org
In Reply to: Re: [gentoo-portage-dev] Re: [RFC] gpkg format proposal v2 by Ulrich Mueller
1 On Mon, 2018-11-12 at 21:23 +0100, Ulrich Mueller wrote:
2 > > > > > > On Mon, 12 Nov 2018, Michał Górny wrote:
3 > > > Also, what would be wrong with ar? It's a standard POSIX tool, and
4 > > > should be available everywhere.
5 > > The original post says what's wrong with ar. Please be more specific
6 > > if you disagree with it.
7 >
8 > AFAICS, the arguments are that ar would be obscure, and that the LSB
9 > considers it deprecated. I don't find either of them convincing.
10 > Since when do we care about the LSB?
11 >
12
13 Do you have a convincing arguments for using ar?
14
15 I think it's quite obvious that tar is the only sane choice for
16 the inner archive format since we need to preserve permissions,
17 ownership etc. ar can't do it.
18
19 Once tar is used for inner archive format, it is also a natural choice
20 for the outer format. If you believe we should use another format, that
21 is introduce a second distinct archive format and depend on a second
22 tool, you need to have a good justification for it.
23
24 So yes, ar is an option, as well as cpio. In both cases the format is
25 simpler (yet obscure), and the files are smaller. But does that justify
26 using a second tool that serves the same purpose as tar, given that tar
27 works and we need to use it anyway? Even if we skip the fact that ar is
28 bundled as part of binutils rather than as stand-alone archiver, we're
29 introducing unnecessarily complexity of learning a second tool.
30 And both ar(1) and cpio(1) have weird CLI, compared to tar(1).
31
32 Plus, ar apparently doesn't support directories, so we end up adding
33 extra complexity to get it unpacked sanely.
34
35 For the record, I've did a little experiment and here are the results:
36
37 -rw-r--r-- 1 mgorny mgorny 112928836 11-12 22:13 wine-any-3.20-1.gpkg.ar
38 -rw-r--r-- 1 mgorny mgorny 112929280 11-12 22:21 wine-any-3.20-1.gpkg.cpio
39 -rw-r--r-- 1 mgorny mgorny 112936960 11-12 22:11 wine-any-3.20-1.gpkg.tar
40
41 So yes, we are saving around 8 KiB... out of 108 MiB. Of course,
42 the savings may become relevant in case of tiny archives but do we
43 really need to be concerned about that?
44
45 The whole point of the proposal is to make the format simpler, easier to
46 introspect and to modify. I believe limiting the number of formats
47 in use certainly serves that purpose while starting to depend on obscure
48 tools in order to save 8 KiB is a case of premature optimization.
49
50 --
51 Best regards,
52 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies

Subject Author
Re: [gentoo-portage-dev] Re: [RFC] gpkg format proposal v2 Ulrich Mueller <ulm@g.o>