Helmut Grohne wrote: > Barring any mistakes this appears like a possible solution to the > problem. Did you spot anything obviously wrong? Any example where you > don't see how to work it out?
It seems correct at first glance, but not enough to solve all the issues mentioned. Currently existing package relationships lack information that is necessary to do the right thing in all cases. Consider different kinds of dependencies a package P can have on package Q: 1) P contains code for <arch> that links with code from Q. Q needs to work for <arch>. 2) P executes a binary provided by Q. Any arch for Q is OK. 3) P runs a script using system interpreter X, and depends on the interpreter environment supporting functionality provided by Q. Q needs to work for the arch matching installed version of X. 4) P runs a script in an embedded interpreter in its <arch> code, and depends on the interpreter environment supporting functionality provided by Q. Q needs to work for <arch>. In the most common case dependencies on a package Q are either all of type 1 or all of type 2, as long as Q only exposes one kind of interface; in the current multiarch spec Q indicates this by "Multi-Arch: same" for 1 and "foreign" for 2. However, dependency types 3 and 4 require adding more information in the depending package to allow determining what arch needs to be supported for Q. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1366422248.1964.26.camel@glyph.nonexistent.invalid