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

Re: multiarch/bi-arch status (ETA) question

Hugo Mills <hugo-64@carfax.org.uk> writes:

> On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote:
>> Stephan Seitz <nur-ab-sal@gmx.de> writes:
>> > On Wed, Jul 06, 2005 at 06:34:26PM +0200, Goswin von Brederlow wrote:
>> >>We are not saying you shouldn't make binaries coinstallable for
>> >>multiple archs, we are only saying we won't make this a policy. It is
>> >>left to each package maintainer to decide if he wants to make the
>> >>multiarch change for his binary too or not and nearly every one will
>> >>not.
>> >
>> > All right, this is a solution I can live with. Until now I thought,
>> > that it would be impossible, even with multiarch, to install two
>> > programs together.
>> It is impossible to install two packages that contain the same
>> filename. Libraries use /usr/lib/arch-os/ to make libs differ between
>> archs.
>    That's not _entirely_ true. In Tollef's multiarch proposal, files
> in /usr/share/doc/<package> can indeed overlap between packages with
> precisely the same name differing only in architecture. My preliminary
> patches to dpkg supported that behaviour.

I think it is best to ignore this special case used for the copyright
and changelog files in the general discussions. /usr/share/doc is
special in that packages may not depend on it being there at all and
messups there (like files disapearing if one of two archs of a package
is purged) may not have affects on the package.

>> Also programs don't depend on something like galeon (i hope).
>    Yes, this is an assumption of Tollef's proposal. Actually, it's
> that programs don't depend on galeon *and care what the architecture
> of that package is*. (I think... don't hold me to that... :) )
>    Hugo.

Yes, things that depend on make have to work with either make flavour.
If that is ever not the case then the depends has to be specialized to
include the architecture required (like plugins will need to).

The assumption is that only a very, very small fraction of packages
will need this change and the breakage of old versions of those is


Reply to: