"Martijn van Oosterhout" <[EMAIL PROTECTED]> writes: > On 5/21/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: >> For multiarch this will be an inconvenience though as people might >> want to install both 32bit and 64bit of a -dev package. For such small >> scripts spliting them into extra packages seems wrong but then you >> have to use alternatives or similar to avoid conflicts. > > Hmm, if a program to be compiled requires libfoo and libbar, and the > user has installed libfoo32-dev and libbar64-dev, where is the error
Under multiarch packages are not renamed. There is libfoo-dev i386 and libfoo-dev amd64. Hopefully they are coinstallable. For core libraries like libc6, zlib, ... this will be pretty much a requirement. > going to be picked up? Are the -dev package actually architecture > sensetive? Every -dev package contains the libfoobar.so -> libfoobar.so.X.Y.Z link. Under multiarch they would be in the architecture specific library directory and thereby not architecture independent. So -dev can not be architecture all. Further, so that one can install both the 32bit and 64bit -dev package it has to set "Multi-Arch: yes", which automaticaly means any depends on it has to match the ABI. If installation of both packages is not possible then the Multi-Arch tag has to be omited, which also causes the ABI to be matched. A libblub-dev with "Depends: libfoo-dev, libbar-dev" then automatically pulls in the same ABI for those 2 packages as it has itself ensuring that they fit. Same would go for Build-Depends (pull in the systems native architecture). > I'd suggest pkgconfig could be used to fix this, except that the > --libs produces too much rubbish to be truly useful (see Bug#340904). > But if it worked correctly, you could add a --arch flags there to > ensure you get the right version. pkgconfig currently has no multiarch support. The *.pc files are architecture dependent and will have to be moved into multiarch directories. But then how will pkgconfig know which one to use? It might have to use and merge all of them creating even more rubbish. This is one of the unsolved problems. > -- > Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]