Re: less dependencies in Debian packages ?
> It is an interesting idea, although I worry about the 'some sort of
> rebuilder script' part. Is it really possible to have sensible
> 'patches' from a base image to versions with extra libraries, or do
> you in fact end up with just a load of different binaries (because the
> differences do not localise well?)
The author of the EDelta utility states :
"EDelta is [...] optimized for executables that have a very systematic
way of changing between versions."
Making patches for binaries built with different options is not exactly
the same usage, and the differences could be scattered among the file,
or the compiler may take different decisions for optimization. But my
early tests didn't show such behavior.
> It seems to me that if all the versions are available then the
> package-size could be large. It depends how well this patching scheme
> works. If it is too larget then you might as well just install the
> deps, as is done now, and still get a smaller system overall.
The package size will grow. I hope not too much, however.
> Do you have any proof-of-concept numbers which would show that the
> binary patches idea actually makes sense numerically?
I tried it with Tracker (a filesystem indexer) :
on the tracker-extract binary:
+---+-------------+--------------+------+
| # | png support | exif support | size |
+---+-------------+--------------+------+
| 1 | no | no | 22547|
+---+-------------+--------------+------+
| 2 | yes | no | 24637|
+---+-------------+--------------+------+
| 3 | no | yes | 25007|
+---+-------------+--------------+------+
| 4 | yes | yes | 27257|
+---+-------------+--------------+------+
+-------+------+
| patch | size |
+-------+------+
| 1 > 2 | 3966 |
+-------+------+
| 1 > 3 | 4309 |
+-------+------+
| 1 > 4 | 5017 |
+-------+------+
| 2 > 4 | 4814 |
+-------+------+
| 3 > 4 | 4057 |
+-------+------+
I also tried to add and remove exif support on the trackerd
binary (870 kb). Although it doesn't link with the exif library,
it still has differences, but the patch is only 3871 bytes.
As I stated before, some work is required to make this realistic,
because EDelta doesn't support n-way patches and is unable to
use the 1>3 patch on binary #2 to obtain #4. Again, differences
in binaries might be more complex and scattered than the ones in
source code, and patches will certainly overlap. Therefore it is
certainly impossible to get incremental patches, and the diff
utility should compare all different versions at once and produce
some sort of patch archive, from which the wanted changes can be
extracted.
Another problem is the number of options available at build :
simple math tells that the number of binaries that must be
produced equals 2^(num_opts). This could be reduced by eliminating
some really uninteresting combinations. Using ccache seems mandatory
too.
JC
Reply to: