Matthias Julius <[EMAIL PROTECTED]> writes:
> Goswin von Brederlow <[EMAIL PROTECTED]> writes:
>
>> 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.
>
> 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.
Nothin prevents libfoo-common and libfoo to have different versions in
unstable making libfoo uninstallable. That is just unstable. Live with
it.
Having multiarch systems require that libfoo is the same versions on
all installed archs is simply an extension of this problem, nothing
new.
Note that nobody is forcing anyone to use multiarch. The design has
always been so that you can selectively add or remove archs to/from
your system. If you don't need a 32bit flash on amd64 then you purge
i386 and run amd64 uniarch. So any extra deadlocks due to version
skews in unstable are your choice. No risk no fun.
>> 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?
No. That is a different problem. This was about not having a -common
package but having dpkg handle file conflicts magically. Best to
forget it since it won't work reliable.
>>> 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?
There is always hope.
The last few days I've been testing a slightly modified multiarch
layout that follows the cross-compiler directory structure. So instead
of /usr/lib/x86_64-linux-gnu I use /usr/x86_64-linux-gnu/lib. This
seems to be well established in binutils already even for non-cross
binutils so no patches needed to make this work. It would also allow
to install the (multiarch) debs from any arch for use with a
cross-compiler. No more conversion or cross building of libs required.
The drawback is that it pollutes / and /usr a bit. But anyone that has
used a cross-compiler is used to that.
> Matthias
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
