[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal for Lenny: Please avoid duplicated changelogs for binary packages sharing the same source package

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.

> 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

> How is multiarch coming along?

In officialy Debian it is stuck with binutils missing a few lines
patch from the BTS.

> Matthias


Reply to: