Re: Debdelta and Streaming Package Installation for dpkg/APT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
hi again,
Il 25/04/2011 07:28, Guillem Jover ha scritto:
> The data.tar does not need to be recompressed for dpkg to be able to
> install it.
(that is true)
> 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...)
> 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.
>> 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.
>
don't know about this; I had a different idea in mind; I will investigate.
>> 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?
yes; I would make sure that debdelta does that (in an internal pipe).
> 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...
> The control files would also need to be
> preserved somewhere, etc.
yes.
a.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk21JyMACgkQ9B/tjjP8QKSyBQCdHoUYPxuzG1GF6bVbtkV0Bvwa
dLoAoIthGSG/SGPdQUrhnk57ovUjROa3
=9U6T
-----END PGP SIGNATURE-----
Reply to: