Wouter Verhelst wrote:
> Hi,
>
> If have nothing of note on the wanna-build side of things, but there's
> one comment I thought I'd make:
>
> On Fri, Jul 03, 2009 at 12:25:45AM +0200, Emilio Pozuelo Monfort wrote:
>> - There's the question as to whether build one .ddeb per source
>> package, or one per binary package. The latter has the advantage
>> that if you want to debug, say, OOo Writter, you don't need to get
>> the debugging symbols for all the other things shipped in OOo.
>> However that would create too many .ddebs. One source package
>> doesn't have this problem, but has the one of being a bit harder to
>> avoid to have somebody with mismatching versions for the .ddeb and
>> the packages the .ddeb provide symbols for. This could be handled
>> with Conflicts though. So one .ddeb per source package sounds like a
>> good option.
>
> There are several packages that build the same source multiple times but
> with differing options. They could do this to have one build with the
> --enable-ldap cnofigure option and one without; or, as in the case of
> curl, one build linked against GnuTLS and one against OpenSSL. As such,
> the debug symbols for both of those binary packages would be different,
> but the file names of the files /containing/ the debug symbols would be
> the same.
>
> This would make an approach of one .ddeb per source package extremely
> difficult, I would say. Have you considered that?
It would be extremely difficult unless we use build-id by default :) E.g.:
emilio@saturno:/tmp$ echo "main(){}" > a.c; echo "int a = 100; main(){}" > b.c;
cp b.c c.c; gcc -o a a.c; gcc -o b b.c; gcc -o c c.c; eu-readelf -n a b c | grep
"Build ID"
Build ID: 535c83fd0fad0970bddaa754dabb002852d8ee89
Build ID: 3da47daeac247f6791b4e5ba1837c6983ca4e070
Build ID: 3da47daeac247f6791b4e5ba1837c6983ca4e070
That is, a.c has one build-id, and b.c and c.c, which are equal, and different
to a, have the same build-id, but different to that of a.c. This way, either
1) the files are different and thus get different build-ids (and no file
conflict), or
2) the files are technically (minus whitespace...) the same, in which case they
get the same build id, but that's ok because their content would be the same. So
in this case we save space shipping only one build id which works fine for both
files.
There's also another possibility though:
3) We get two different files with the same build id. This is very unlikely, as
the default hash for the build id is sha1. I wouldn't consider this a problem,
at least for now.
However there's another problem:
4) different source packages (foo and bar) build the same binary ("main(){}"),
thus they get the same build id and a file conflict between their ddebs. This is
ok if they could be coinstalled, since the symbols would be the same, but the
packages won't be co-installable. I don't know how likely it is to get into this
situation (since you need the file to be linked separately), but it could be a
good way for the security team to find duplicated code ;)
Cheers,
Emilio
Attachment:
signature.asc
Description: OpenPGP digital signature