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

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

GOMBAS Gabor <gombasg@sztaki.hu> writes:

> On Wed, Jul 06, 2005 at 08:20:38PM +0200, Goswin von Brederlow wrote:
>
>> Also programs don't depend on something like galeon (i hope).
>
> $ apt-cache show liferea-mozilla
> [...]
> Depends: liferea (= 0.9.1-1), mozilla-browser, [...]
>
> Gabor

Does that dlopen mozilla? In that case it needs to specify the
architecture it needs (only if mozilla sets "Multi-arch: no"). If it
just fork()s and exec()s mozilla then an abi change is perfectly fine.

Mozilla might even never convert over to "Multi-arch: no" given that
it has so many plugins and is very high in dependency trees.


This is one thing that is unsaid or unclear in the multiarch
proposal. Packages can have one of 3 types:

1. Multi-arch: yes

   This is a library package. Any number of architectures of this
   package can be installed at the same time and packages depending on
   it require the same abi to fullfill the depends.

   E.g. libc6

2. Multi-arch: no

   This is a program with command line interface. Only one
   architecture of this package can be installed and packages
   depending on this will work with any arch.

   E.g. make

3. no Multi-arch entry

   This package is not multiarch aware/ready/capable. All existing
   packages fall into this case and backwards compatibility has to be
   maintained. We can't assume anything about this package and that
   means:
   - only one architecture of this package can be installed
   - packages depending on it require the same abi (this could be a lib)

At the start all packages are type 3. That means that you can only
install debconf 32bit or 64bit but not both. In turn, if you have
32bit debconf installed, you can only install 32bit flavours of
anything with Depends: debconf.

Since that is a big pain debconf (and any other frequently depended
upon program) have to change to type 2 (which means _only_ adding that
one line in control).


This sounds like a lot of unneccesary work (hey, why not assume type 2
if unset?) but it is the only way that will not break existing
packages. Think about it for a while before you reply.

MfG
        Goswin