Re: Upcoming Debian multiarch support (amd64, sparc64, s390x, mips64) [affects sarge slightly]

[Andreas Metzler <ametzler@downhill.at.eu.org>]

Scott James Remnant <scott@netsplit.com> wrote:
> On Sun, 2004-01-11 at 19:54, Goswin von Brederlow wrote:
>> Scott James Remnant <scott@netsplit.com> writes:
>>> On Sun, 2004-01-11 at 18:15, Goswin von Brederlow wrote:

>>>> The thing is you still have one package, one name. You just have
>>>> multiple debs providing different ABIs of the same package. I can just
>>>> as well say that renaming libc6 to lib64c6 breaks the one package, one
>>>> name rule. One package (libc6) now has two names (libc6 and lib64c6).
>>>> 
>>> libc6 includes much more than just /lib/* though, what do you do with
>>> all the other files?  How are you going to handle the conflict between
>>> /usr/share/zoneinfo from libc6:i386 and the same from libc6:ia64?

>> Irelevant to the problem of renaming or not renaming debs. The common
>> files must be split out into a bianry-all package or some "silently
>> overwrite" rule must be devised.

> Why?  So you're stating that for your method to work you're going to
> need to fundamentally change many library packages?

[...]
>> Only lib packages are suposed to have two abis installed at the same
>> time. Files in bin and bin64 should allways be disjunct so splitting
>> them is not neccessary. Same for sbin and games.

> Sorry, where did you pick this "should" up from?  Don't go adding
> "should"s where "should" doesn't exist.  Neither policy nor practice
> suggest that you can't stick support binaries into a library package.
[...]

Actually policy 8.2 does, explicitely.
| If your package has some run-time support programs which use the
| shared library you must not put them in the shared library package.
| If you do that then you won't be able to install several versions
| of the shared library without getting filename clashes.

However this does not seem to be enforced strictly,
               cu andreas

-- 
Hey, da ist ein Ballonautomat auf der Toilette!
Unofficial _Debian-packages_ of latest unstable _tin_
http://www.logic.univie.ac.at/~ametzler/debian/tin-snapshot/