Re: Packages violating policy 8.2
"Martijn van Oosterhout" <email@example.com> writes:
> On 5/21/06, Goswin von Brederlow <firstname.lastname@example.org> 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
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@example.com> http://svana.org/kleptog/