[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

MultiArch standoff: apt vs dpkg vs deb-control(5)


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

Reply to: