Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> writes:
> Matthias Julius <lists@julius-net.net> writes:
>
>> Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> 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.
There is nothing that guaranties that libc6 is on the same version on
all arches (at least in unstable). If it is not your second choice
becomes uninstallable.
Multiarch packages would need to be blocked from upgrading in the
archive until the new version is available on all arches that can run
on the same platform.
>
> 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.
Doesn't this problem already exist for packages that have a separated
-common or -data package? What is worse in multiarch if the arches
are force to be on the same version?
>
>> How is multiarch coming along?
>
> In officialy Debian it is stuck with binutils missing a few lines
> patch from the BTS.
Is there hope that gets resolved after etch?
Matthias