Re: Debdelta and Streaming Package Installation for dpkg/APT
On Mon, 2011-04-25 at 09:47:47 +0200, A Mennucc wrote:
> Il 25/04/2011 07:28, Guillem Jover ha scritto:
> > But my main problem right now is that I didn't find clear
> > documentation of the “debdelta” file format, the closest thing that I
> > found was the debpatch  example file in the debdelta package.
> (unfortunately the problem is that, from 2005 to ~two months ago, I
> was the only one working on debdelta.. so the documentation is mostly
> in my head...)
Sure. I think just documenting the file format, and nothing else, would
be enough to get a clear idea of how all this works, and at least for
me how to try to integrate it, and where. It would not need to be too
> > Something that I found undesirable is that it seems to require executing
> > a shell script included in the debdelta package to regenerate the data?
> yes. Why would that be undesirable? Shell scripts are simple, well
> known, and very powerful. (Indeed they are often used also for
> "postinst" etc etc in deb packages...). Using shell scripts for
> patches was a design decision in 2005 that I am quite happy of: it
> enabled me to ameliorate the patches a lot in the following years,
> without ever changing the delta internal format.
While I can understand that it makes changing the format easier, and
it was probably the right tool for fast prototyping, it also implies
the file cannot be automatically inspected/verified/handled w/o
implicitly trusting it. Which I don't think it's a good property for
a file format.
The case you mention about maintainer scripts is not equivalent, as
they are only run on installation/etc, and not on say dpkg-deb
extraction (say -I, -c, -f, etc), or when joining split packages
> > Anyway I don't quite like the idea, it would imply
> > offloading some of the dpkg unpacking logic out of dpkg, or just
> > duplicating it inside dpkg itself to deal with unpacking from tar
> > and from the file system itself and to rely safely on the file metadata
> > from the binary package.
> yes that second one would be my idea. Well, in all ways we think of it
> , since there is an overlap we may want to eliminate, then either we
> bring some logic of debdelta into dpkg, or some logic of dpkg into
So, my first instinct would be to bring that logic into dpkg (or a new
dpkg-debdelta or whatever), instead of offloading it, but as mentioned
earlier I don't think I've enough understanding of how debdelta works
internally to know how the integration could happen, or if that would
be the best way to do it.