Adam Borowski writes:
> On Mon, May 13, 2019 at 11:25:11AM +0200, Ansgar wrote:
>> It supports solid compression[1] which
>> compresses multiple files into one block like tar.xz, but unlike tar.xz
>> can use more than one block: "Later versions of 7-zip use a variable
>> solid block size, so that o
On Mon, May 13, 2019 at 11:25:11AM +0200, Ansgar wrote:
> On Fri, 2019-05-10 at 16:11 +0200, Adam Borowski wrote:
> > /usr on the box I'm sitting at:
> > * zip the program: dies horribly due to /usr/lib/llvm-7/build/
> > symlink
> > loops.
> > * zip:
> > 1891345142 bytes
> > * zip-the-concept
Hi Adam,
On Fri, 2019-05-10 at 16:11 +0200, Adam Borowski wrote:
> /usr on the box I'm sitting at:
> * zip the program: dies horribly due to /usr/lib/llvm-7/build/
> symlink
> loops.
> * zip:
> 1891345142 bytes
> * zip-the-concept (individually compressed files), xz
> 1516943024 byte
On Fri, 2019-05-10 at 11:04 +0200, Thomas Goirand wrote:
> On 5/9/19 6:25 PM, Andrej Shadura wrote:
> > How about the format opkg used for some time, which is a .deb file
> > but
> > with tar as the outer container format instead of ar?
>
> This is a very bad idea. When installing a large amount o
On Fri, 2019-05-10 at 05:18:18 +0200, Guillem Jover wrote:
> I'll propose an actual diff I've got here of deb(5) tomorrow, but
> otherwise if there are no great concerns, I'd like to start adding
> support for this for dpkg 1.20.x.
Unfortunately I think I'll have to retract the above statements, a
On Fri, May 10, 2019 at 09:15:49PM +0100, Ian Jackson wrote:
> dpkg-deb has a built-in decoder for the subset of ar that is used for
> deb(5). One reason I chose ar rather than tar is that handwriting a
> decoder for ar was much simpler than for tar.
I wonder then, why the speed loss? A good ar
On Sat, 2019-05-11 at 12:08:05 +0100, Ian Jackson wrote:
> John Goerzen writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
> > Plus, of course, when discussing tar, there is always the "which tar
> > format do you mean?" question.
> >
>
John Goerzen writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
> Plus, of course, when discussing tar, there is always the "which tar
> format do you mean?" question.
>
> https://manpages.debian.org/stretch/libarchive-dev/tar.5.en.html
Quite.
On Fri, 10 May 2019 11:50:17 -0400, Michael Stone
wrote:
>On Fri, May 10, 2019 at 05:42:45PM +0200, Marc Haber wrote:
>>On Fri, 10 May 2019 07:42:52 -0400, Michael Stone
>>wrote:
>>>This is really not a property worth preserving.
>>
>>I disagree. I frequently unpack .debs on .rpm Systems, especia
On Fri, May 10 2019, Ian Jackson wrote:
>> On my embedded systems, I don't have ar installed, only tar.
>> I assume, that dpkg speaks ar natively?
>
> dpkg-deb has a built-in decoder for the subset of ar that is used for
> deb(5). One reason I chose ar rather than tar is that handwriting a
> de
W. Martin Borgert writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
> Quoting Sam Hartman :
> > I've certainly heard people describe our use of both ar and tar as an
> > architectural minus especially on embedded platforms just because the
>
>> I did used ar to unpack .deb several times, usually when I had to pull a file
>> on a non-Debian system (or when I could not remember the dpkg-deb syntax
>> and I was lazy, but that doesn’t count :)
> same here. and not only this millenium, but also this decade :)
ar(1) is the only thing I've
On Fri, May 10, 2019 at 05:42:45PM +0200, Marc Haber wrote:
On Fri, 10 May 2019 07:42:52 -0400, Michael Stone
wrote:
This is really not a property worth preserving.
I disagree. I frequently unpack .debs on .rpm Systems, especially when
I want to see how the rather nice behavior that I find in
On Fri, 10 May 2019 07:42:52 -0400, Michael Stone
wrote:
>This is really not a property worth preserving.
I disagree. I frequently unpack .debs on .rpm Systems, especially when
I want to see how the rather nice behavior that I find in Debian is
implemented to see whether I can implant that hotnes
On Fri, May 10, 2019 at 02:49:01PM +0200, W. Martin Borgert wrote:
> Quoting Sam Hartman :
> > I've certainly heard people describe our use of both ar and tar as an
> > architectural minus especially on embedded platforms just because the
> > dependency set of dpkg needed to be larger.
>
> On my e
Quoting Sam Hartman :
I've certainly heard people describe our use of both ar and tar as an
architectural minus especially on embedded platforms just because the
dependency set of dpkg needed to be larger.
On my embedded systems, I don't have ar installed, only tar.
I assume, that dpkg speaks a
> "Michael" == Michael Stone writes:
Michael> On Fri, May 10, 2019 at 05:18:18AM +0200, Guillem Jover wrote:
>> be updated anyway to support any new format. It also destroys
>> some of the nice properties of the 2.x format, namely:
>>
>> - Not requiring special tools to b
On Fri, May 10, 2019 at 05:18:18AM +0200, Guillem Jover wrote:
be updated anyway to support any new format. It also destroys some of the
nice properties of the 2.x format, namely:
- Not requiring special tools to build/extract.
This is really not a property worth preserving. I think it would
Adam Borowski writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
> It's not possible to peel away the outer layer as tar doesn't guarantee the
> data is contiguous in the file. It supports sparse files, etc.
If we were to use tar as a format we would s
On Fri, May 10, 2019 at 11:30:14AM +0200, Andrej Shadura wrote:
> On Fri, 10 May 2019 at 06:47, Adam Borowski wrote:
> > > So I think Andrej is on the spot, and we should just switch from ar(5)
> > > to tar(5) as the container
> >
> > I would heavily advise against archive-in-archive. Especially
On 5/9/19 6:25 PM, Andrej Shadura wrote:
> Hi,
>
>
> On Thu, 9 May 2019, 15:57 Ian Jackson, <mailto:ijack...@chiark.greenend.org.uk>> wrote:
>
> Ansgar writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
> > `ar` needs to be
On Fri, May 10, 2019 at 10:59:26AM +0700, Ondřej Surý wrote:
> > I understand that this was an issue when prototyping, but have you used ar
> > to manipulate .deb archives even once this millenium? By now, the deb
> > format is common, while ar is an obscure implementation detail.
> I did used ar
Ian Jackson writes:
> Ansgar writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
>> `ar` needs to be replaced for the file size limitation mentioned in the
>> initial mail: ar represents file size as a 10 digit decimal number[1]
>> which limits the me
On Fri, May 10, 2019 at 05:18:18AM +0200, Guillem Jover wrote:
> On Wed, 2019-05-08 at 19:38:26 +0200, Adam Borowski wrote:
> > First, the 0.939 format, as described in "man deb-old". While still being
> > accepted by dpkg, it had been superseded before even the very first stable
> > release. Why
> On 10 May 2019, at 10:39, Adam Borowski wrote:
>
> I understand that this was an issue when prototyping, but have you used ar
> to manipulate .deb archives even once this millenium? By now, the deb
> format is common, while ar is an obscure implementation detail.
I did used ar to unpack .d
On Wed, May 08, 2019 at 09:53:19PM +0100, Ian Jackson wrote:
> (adding debian-dpkg)
Probably too late to move the thread :(
> Adam Borowski writes (".deb format: let's use 0.939, zstd, drop bzip2"):
> > First, the 0.939 format, as described in "man deb-old". While still being
> > accepted by dp
Hi!
On Wed, 2019-05-08 at 19:38:26 +0200, Adam Borowski wrote:
> First, the 0.939 format, as described in "man deb-old". While still being
> accepted by dpkg, it had been superseded before even the very first stable
> release. Why? It has at least two upsides over 2.0:
I'll try to detangle the
Hi,
On Thu, 9 May 2019, 15:57 Ian Jackson,
wrote:
> Ansgar writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
> > `ar` needs to be replaced for the file size limitation mentioned in the
> > initial mail: ar represents file size as a 10 digit decimal
Ansgar writes ("Re: .deb format: let's use 0.939, zstd, drop bzip2"):
> `ar` needs to be replaced for the file size limitation mentioned in the
> initial mail: ar represents file size as a 10 digit decimal number[1]
> which limits the members (control.tar.*, data.tar.*)
On Thu, 2019-05-09 at 12:32 +, Jeremy Stanley wrote:
> On 2019-05-09 06:27:36 +0900 (+0900), Mike Hommey wrote:
> > On Wed, May 08, 2019 at 09:04:49PM +, Jeremy Stanley wrote:
> [...]
> > > Are you talking about source packages or binary packages here?
> > > The
> > > latter use ar, not tar
On 2019-05-09 06:27:36 +0900 (+0900), Mike Hommey wrote:
> On Wed, May 08, 2019 at 09:04:49PM +, Jeremy Stanley wrote:
[...]
> > Are you talking about source packages or binary packages here? The
> > latter use ar, not tar.
>
> Binary packages use both.
>
> $ ar t /var/cache/apt/archives/libg
On Thu, May 09, 2019 at 09:22:56AM +0200, Ansgar wrote:
> Also dpkg keeps metadata in /var, but changelogs, NEWS, copyright
> documentation isn't variable state data and should be below /usr... The
> same is really true for lists of files and maintainer scripts though.
It's a mess:
* Most of the
On Thu, May 09, 2019 at 08:10:00AM +, Anthony DeRobertis wrote:
> On May 8, 2019 9:43:50 PM UTC, Adam Borowski wrote:
>
> >I just checked Stretch: not a single .bz2, either control nor data. I'm
> >not going to download all of Jessie just to check -- but even assuming
> >something was left b
On May 8, 2019 9:43:50 PM UTC, Adam Borowski wrote:
>I just checked Stretch: not a single .bz2, either control nor data.
>I'm not
>going to download all of Jessie just to check -- but even assuming
>something
>was left by Jessie's time, by Bullseye trying to install such a .deb
>will
>mean mi
On Wed, May 08, 2019 at 09:01:27PM -0400, Michael Stone wrote:
> On Thu, May 09, 2019 at 07:37:55AM +0800, Paul Wise wrote:
> > On Thu, May 9, 2019 at 1:38 AM Adam Borowski wrote:
> >
> > > Thus, even though we'd want to stick with xz for the official archive,
> > > speed
> > > gains from zstd ar
Adam Borowski writes:
> On Wed, May 08, 2019 at 10:35:58PM +0200, Ansgar wrote:
>> Adam Borowski writes:
>> > I've recently did some research on how can we improve the speed of
>> > unpacking
>> > packages. There's a lot of other stages that can be improved, but let's
>> > talk about the .deb for
On Thu, May 09, 2019 at 12:02:26AM +0200, Adam Borowski wrote:
> > We have various applications that only want to extract single members of
> > the package (changelog, NEWS, copyright, ...); tar is a really bad
> > format for such an operation. Other formats (zip, 7z, ...) are more
> > suited for
On Thu, May 09, 2019 at 07:37:55AM +0800, Paul Wise wrote:
On Thu, May 9, 2019 at 1:38 AM Adam Borowski wrote:
Thus, even though we'd want to stick with xz for the official archive, speed
gains from zstd are so massive that it's tempting to add support for it,
at least for non-official uses, po
On Thu, May 9, 2019 at 1:38 AM Adam Borowski wrote:
> Thus, even though we'd want to stick with xz for the official archive, speed
> gains from zstd are so massive that it's tempting to add support for it,
> at least for non-official uses, possibly also for common Build-Depends.
Could we use cust
On Wed, May 08, 2019 at 10:35:58PM +0200, Ansgar wrote:
> Adam Borowski writes:
> > I've recently did some research on how can we improve the speed of unpacking
> > packages. There's a lot of other stages that can be improved, but let's
> > talk about the .deb format.
> >
> > First, the 0.939 form
On Wed, May 08, 2019 at 09:04:49PM +, Jeremy Stanley wrote:
> On 2019-05-08 22:35:58 +0200 (+0200), Ansgar wrote:
> > Adam Borowski writes:
> > > I've recently did some research on how can we improve the speed of
> > > unpacking
> > > packages. There's a lot of other stages that can be improv
On Wed, May 08, 2019 at 10:45:21PM +0300, Adrian Bunk wrote:
> On Wed, May 08, 2019 at 07:38:26PM +0200, Adam Borowski wrote:
> > So let's pick compressors to enable. For compression ratio, xz still wins
> > (at least among popular compressors). But there's a thing to say about
> > zstd: firefox.
Jeremy Stanley writes:
> On 2019-05-08 22:35:58 +0200 (+0200), Ansgar wrote:
>> Switching to a different binary format will break various tools. If we
>> want to do this, I wonder if we shouldn't take the chance to move away
>> from tar?
>>
>> We have various applications that only want to extrac
On 2019-05-08 22:35:58 +0200 (+0200), Ansgar wrote:
> Adam Borowski writes:
> > I've recently did some research on how can we improve the speed of unpacking
> > packages. There's a lot of other stages that can be improved, but let's
> > talk about the .deb format.
> >
> > First, the 0.939 format,
(adding debian-dpkg)
Adam Borowski writes (".deb format: let's use 0.939, zstd, drop bzip2"):
> First, the 0.939 format, as described in "man deb-old". While still being
> accepted by dpkg, it had been superseded before even the very first stable
> release. Why? It has at least two upsides over
Adam Borowski writes:
> I've recently did some research on how can we improve the speed of unpacking
> packages. There's a lot of other stages that can be improved, but let's
> talk about the .deb format.
>
> First, the 0.939 format, as described in "man deb-old". While still being
> accepted by
Adrian Bunk - 08.05.19, 21:45:
> On Wed, May 08, 2019 at 07:38:26PM +0200, Adam Borowski wrote:
> >...
> >
> > So let's pick compressors to enable. For compression ratio, xz
> > still wins (at least among popular compressors). But there's a
> > thing to say about zstd: firefox.deb zstd -19 takes
Le 08/05/2019 à 19:38, Adam Borowski a écrit :
> Hi!
> I've recently did some research on how can we improve the speed of unpacking
> packages. There's a lot of other stages that can be improved, but let's
> talk about the .deb format.
>
> First, the 0.939 format, as described in "man deb-old".
On Wed, May 08, 2019 at 07:38:26PM +0200, Adam Borowski wrote:
>...
> So let's pick compressors to enable. For compression ratio, xz still wins
> (at least among popular compressors). But there's a thing to say about
> zstd: firefox.deb zstd -19 takes to unpack:
> * 2.644s .xz, stock dpkg
> * 2.5
> "Adam" == Adam Borowski writes:
Adam> Hi! I've recently did some research on how can we improve the
Adam> * there's no 10¹⁰ bytes (~9.31GB) limit While no package this
Adam> big is in the archive _yet_ (max being 1⎖652⎖244⎖360 bytes),
Adam> both storage sizes and software b
50 matches
Mail list logo
