Questions about the amd64-multiarch-3 proposal

[Bill Allombert <allomber@math.u-bordeaux.fr>]

Hello fellows developers,

I have some comment on the amd64-multiarch-3 proposal
<http://people.debian.org/~ajt/amd64-multiarch-3.txt>

First I think this update go in the right direction, at least it does
not look like a large kludge, but I need some clarification.

I will assume, while it is not stated explicitly that amd64-multiarch-3
follow  amd64-multiarch-2 w.r.t. the introduction
/usr/$(gcc -dumpmachine)/{lib,include}

Without this assumption the proposal make no sense.

                   =========

Extracted from amd64-multiarch-3.txt:
> we want the development stuff to be multiply installable (why the hell
> not?).

[Of course there is no reason, unless it is too unpractical to do so.]

>        lib<foo><n>-<arch>
>               - .so file
>                - libfooN-x, libfooM-x, libfooN-y must all be concurrently
>                  installable
                  
If you ship the .so symlink here, how will you have libfooN-x and libfooM-x
concurently installable ? They both include the libfoo.so symlink.
This is for this reason the .so symlink is in the -dev package. 
(Unless you meant libfoo.so.N, in this case please clarify in a future
version.)

>        lib<foo><n>-dev-<arch>

[The concurrent install possible is probably only libfooN-x with libfooN-y]

>                - .a file
>                - arch-dependent include files


>        lib<foo><n>-dev-common

[Probably no concurrent install possible]

>                - arch: all
[Probably the .so symlink belong here]
>                - manpages, arch-independent include files



While that sound like a good idea, how that will be implement?
1) Where arch-dependent include files will be put 
         [/usr/$(gcc-dumpmachine)/include]
1) Where arch-independent include files will be put [/usr/include ?]

Will gcc search first in
/usr/$(gcc -dumpmachine)/{lib,include}
and if nothing is found will look in /usr/include ?

How relative header path will be handled ?
(For example
-8<-/usr/include/foo/foo.h----
#include "foo-arch.h"
#include "foo-all.h"
------------------------------

---8<-----bar.c---------------
#include <foo/foo.h>
int main(void) { return foo(42); }
------------------------------

Now user issue
gcc -c bar.c

info cpp state that:
`#include "FILE"'
     This variant is used for header files of your own program.  It
     searches for a file named FILE first in the directory containing
     the current file, then in the same directories used for `<FILE>'.

Under current cpp semantic, cpp will search foo-arch.h and
foo-all.h in /usr/include/foo was found and
then in /usr/$(gcc -dumpmachine)/include and /usr/include 
bu not in _both_ /usr/$(gcc -dumpmachine)/include/foo.

So if foo-arch.h is arch-dependent, it will not be found. 

This flaw is not critical since we can decide to ship all the include
files in lib<foo><n>-dev-<arch> in this case.

I see two remaining uncertainty
1) Were does the .so symlink go ?
2) Should -dev-common depend on -dev-arch (even after the transitional 
period?)

I apologize in advance for all the misunderstanding.

Cheers,
-- 
Bill. <ballombe@debian.org>

Imagine a large red swirl here.