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 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, 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
>
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
On Fri, 10 May 2019 at 06:47, Adam Borowski wrote:
> > The crazy idea I came up with at the time was to use a dual-format PAX+ar
> > container (that would embed the ar(5) header in the first PAX name entry).
> > This would make old tools at least detect this is a .deb package, with a
> > higher ma
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
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
(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.
13 matches
Mail list logo
