Matthias Julius <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> 2) multiarch has a problem with changelogs in library packages. It
>> must be possible to insall libc6:i386 and libc6:amd64. If both contain
>> /usr/share/doc/libc6/changelog then that gives a file conflict in
>> dpkg. Having the changelog in libc6-common beautifully solves this
>> problem and avoids having to special case this in dpkg.
>
> There is one more catch to add here: The same library can be installed
> in different versions for the different arches. IMHO this makes it
> impossible for them to really share the same file.
Not neccessarily. I wouldn't really get upset if libc6 depends on
libc-common (= source:version) and forces libc6:i386 and libc6:amd64
to be the same version at all times.
> I think the possibly cleanest solution is to install the docs in
> directories with an arch specific suffix, e.g. doc/libc6_i386 and
> doc/libc6_amd64. The debhelper scripts could do that for multiarch
> packages.
>
> But, what do you do with conflicting man pages?
Same solution: libc6-common contains the manpages and common include
files etc. There can be no easy dpkg magic to rename them since then
they won't work.
You can't assume the i386 /usr/share/* files will work for the amd64
package if you allow the versions to differ and even if versions are
forced to match it would be complex to handle up/down-grades
correctly. For /usr/share/doc we can hack around as that dir must be
unimportant to the workings of a package. Not so for /usr/share/* in
general.
> How is multiarch coming along?
In officialy Debian it is stuck with binutils missing a few lines
patch from the BTS.
> Matthias
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
