Re: Debdelta and Streaming Package Installation for dpkg/APT
Hi!
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 [1] 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
exhaustive though.
> > 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
with dpkg-split.
> > 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
> debdelta...
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.
thanks,
guillem
Reply to: