Re: Debdelta and Streaming Package Installation for dpkg/APT
Hi!
On Sun, 2011-04-24 at 23:44:25 +0200, A Mennucc wrote:
> here is a reply to a message you sent me long ago; this message also
> referenced a message in debian-dpkg [1], so I am CC-ing them as well.
Ah perfect, had in mind talking about the apt/debdelta integration
GSoC proposal [0] with you guys, but have not had the time to check
several details, anyway here it is, still with some facts not checked.
[0] <http://wiki.debian.org/SummerOfCode2011/AptDebdeltaIntegration>
> Let me summarize. When 'debdelta-upgrade' (or 'debpatch') recreates a
> deb, one step is reassembling the data.tar part inside it; this part
> moreover is compressed (gzip, bzip2 or lately lzma). This
> 'reassembling and compressing' takes time (both for CPU and for HD),
> and is moreover quite useless, since, in short time, 'apt' will call
> 'dpkg -i' that decompresses and reopens the data.tar in the deb.
The data.tar does not need to be recompressed for dpkg to be able to
install it. 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.
Something that I found undesirable is that it seems to require executing
a shell script included in the debdelta package to regenerate the data?
[1] /usr/share/debdelta/debpatch.sh
> It is then reasonable to collapse this two parts, and this would
> possibly speed up the upgrade a bit.
Yeah, AFAIUI the debdelta side seems to be similar in nature to
dpkg-split (specifically the --auto command), so I think it might make
more sense to integreate that part into dpkg instead of apt. At least
the retrieving part would still need to be integrated into apt though.
> Here is my idea. When 'debdelta-upgrade' is called in upgrading a
> package 'foobar' it currently creates 'foobar_2.deb'. By an
> appropriate cmdline switch, instead of creating a 'foobar_2.deb' , it
> would directly save all of its file to the filesystem, and it would
> add an extension to all the file names, making sure that no file name
> would conflict (=overwrite) with a preexisting file on the filesystem
> ; then it would create a file 'foobar_2.deb_unpacked' , that would be
> just a text file similar to the usual control file, but specifying
> also the extension used, and possibly the list of unpacked files.
Well, doesn't it have to verify the reconstructed package matches the
expected one? 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.The control files would also need to be
preserved somewhere, etc.
thanks,
guillem
Reply to: