Re: Multi-arch all-architecture plugins
Peter Samuelson writes ("Re: Multi-arch all-architecture plugins"):
> [Ian Jackson]
> > Where should this fact be declared ? Is it a property of a package
> > that it makes sense to install it only on all configured architectures
> > or none ? Or is it a property of the dependency from the depending
> > package ?
> Neither. If I've configured i386 on an amd64 system just to install 2
> binaries and libc6, but on amd64 I've installed, say, a gimp plugin, I
> don't want to have to install, on i386, not only this same plugin but
> also libgimp and its dependency tree, including the whole Gtk stack.
Your example, gimp plugins, is a bit different to the one I had in
If you install on i386 your 2 binaries and libc6, you /do/ need the
i386 libfakeroot. Otherwise if you say "fakeroot <your binary>" it
won't work, no matter that /usr/bin/fakeroot is amd64.
Whereas if you have gimp installed you /either/ have the amd64 or the
i386 version, and all your gimp plugins need to be the same
architecture. If for some reason you have the i386 gimp even though
your primary arch is amd64, you don't want "apt-get install
gimp-plugin-swirly" to install gimp-plugin-swirly_amd64.deb.
However, it turns out that this case is easily solved: the gimp plugins
all depend on gimp:
Depends: [ lots of stuff ], gimp (>= 2.0)
Now in the multiarch world we will have
so by default that dependency would be satisfied. But if we do this
Depends: [ lots of stuff ], gimp:i386 (>= 2.0)
then the package manager can tell that this isn't the one it wants and
that instead it should install:
Depends: [ lots of stuff ], gimp:amd64 (>= 2.0)
And indeed the plugin itself need not have a multi-arch field because
it doesn't need to be coinstalled with other arches.
So that deals with that case. But there is also this:
> Package: libsasl2-modules
> Multi-Arch: same-as libsasl2-2
Would it matter if the list of sasl modules installed was different on
different architectures ? Would that mean that i386 sasl-using
applications would have different sasl capabilities or would it cause
libsasl not to start up due to missing plugins ?