Hi, I had some time over the weekend, so I thought: What could be more fun than implementing pkg:<arch> in apt as agreed on in the DebConf BoF? Somehow I ended up doing it anyway… but while I took my cleanroom implementation for a ride comparing it to dpkg and actually reading the documentation I stumbled over a few things which are either bugs in apt or dpkg or the documentation in deb-control. Lets decide together… What follows is a list of observations/comments in semi-random order: -- In the "The syntax of Breaks, Conflicts and Replaces is" paragraph its said that 'any' is the default. The previous syntax-paragraph defines 'any' in relation to M-A:allowed through, so reusing this word here might not be ideal. This 'any' makes no sense in negative dependencies anyway (or maybe it does …?!?), so maybe just redefine it. The same problem exists in deb-src-control(5) just that the two different meanings appear in consecutive sentences… -- In "Provides" architecture-specific provides are explicitly allowed, but combining this with the previous mentioned paragraph we get: Package: foo Architecture: amd64 Conflicts: bar-prv:amd64 Package: bar Architecture: i386 Provides: bar-prv:armel Trying to install both causes dpkg to say "bar-prv:i386 provides bar-prv" and fail. I would have expected it to work. With positive dependencies this works (as seen below), so that smells either like a dpkg bug or I have totally misunderstood the documentation, but I faintly remember stumbling over this already some time ago… -- Surprisingly (on first look at least) Package: foo Architecture: amd64 Depends: bar-prv:armel Package: bar Architecture: i386 Provides: bar-prv:armel Works as 'expected' even through armel is not configured. That is interesting in so far as this can be bar-prv:any, too, which punches a small hole in the definition what can satisfy an :any dependency – it could come in handy for packages changing from M-A:allowed to M-A:foreign through as this avoids the need for a flagday, so officially documenting it would be good if its intended. -- In my testing I couldn't use dpkg --no-act as this 'happily' segfaults with (the packaged dpkg does as well, just that the stacktrace is useless without debug symbols, so I built my own dpkg from git): Reading symbols from /home/david/Öffentlich/debian/dpkg/build-tree/src/dpkg...done. Starting program: /home/david/Öffentlich/debian/dpkg/build-tree/src/dpkg --root=/tmp/tmp.iZg438M678/rootdir --log=/tmp/tmp.iZg438M678/rootdir/var/log/dpkg.log --force-not-root --force-bad-path --no-act -i incoming/bar_1_i386.deb incoming/foo_1_amd64.deb Program received signal SIGSEGV, Segmentation fault. 0x000000000041a71d in pop_cleanup (flagset=flagset@entry=1) at ../../../lib/dpkg/ehandle.c:324 324 econtext->cleanups= cep->next; (gdb) bt #0 0x000000000041a71d in pop_cleanup (flagset=flagset@entry=1) at ../../../lib/dpkg/ehandle.c:324 #1 0x0000000000424b78 in trigdef_process_done () at ../../../lib/dpkg/trigdeferred.l:248 #2 0x0000000000423382 in trig_incorporate (cstatus=msdbrw_readonly) at ../../../lib/dpkg/triglib.c:816 #3 0x0000000000418540 in modstatdb_open (readwritereq=<optimized out>) at ../../../lib/dpkg/dbmodify.c:296 #4 0x0000000000405d96 in archivefiles (argv=0x7fffffffe020) at ../../src/archives.c:1435 #5 0x0000000000402e79 in main (argc=<optimized out>, argv=0x7fffffffe020) at ../../src/main.c:899 cep is a null pointer (and got it from econtext->cleanups one line above). Being silly and just returning from the function early if its a null pointer gives me the expected success result btw, not like the real deal who fails as mentioned above… but I have no idea what is supposed to happen in pop_cleanup so that might be expected… -- In the "Provides" syntax paragraph it is said that if the architecture is omitted, it is the architecture of the package. Given: Package: foo Architecture: amd64 Depends: bar-prv Package: bar Architecture: i386 Provides: bar-prv Multi-Arch: foreign This seems wrong. It suggests that "Provides: bar-prv:i386" would be an equivalent line, but that makes the situation unsatisfiable. Worse, if we change the previous situation slightly to: Package: foo Architecture: amd64 Depends: bar-prv:any Package: bar Architecture: i386 Provides: bar-prv Multi-Arch: allowed We have again a situation in which :any documentation is stretched to its limits and Provides doesn't deal with it at all (oh and yes, this situation is supported by dpkg – and apt now). -- In the "The syntax of Breaks, Conflicts and Replaces" paragraph we are told that for the first two a comma should be read as "OR". What is with Replaces? In deb-src-control(5) we read a comma as "AND" in Build-Conflicts btw. -- In fact, the first sentence of the Replaces documentation: I know what is meant, but… this "files" is at a very strange place. And shouldn't Breaks be used here given that Replaces is actually not needed (usually) if you use the (bigger) Conflicts hammer as the file you want to override is already gone… -- I have still some cleanup/testing to do and I am better at mis- interpreting and criticising than writing documentation, so I will refrain from suggesting other wordings for now – also to not blow up the mail length further. Best regards David Kalnischkies
Attachment:
signature.asc
Description: Digital signature