Re: Multi-arch all-architecture plugins
[Goswin von Brederlow]
> Except is gimp the only way to use gimp plugins? Isn't there another app
> foo that also uses libgimp and its plugins? Then you could have
> gimp:amd64, foo:i386.
Actually ... if I remember correctly, gimp plugins are executables, not
libraries, so really they should be M-A: foreign. So, not really
relevant to this discussion after all.
> So "Multi-Arch: same-as glibc-2.13-1" would be fine. Even "Multi-Arch:
> libc" would be fine (if it is provided).
The problem with M-A: same-as glibc-2.13-1 is that it means you need to
binNMU (or even source NMU) every nss plugin for every major glibc
release. So, it would be nice to use something more generic. But, at
the moment, libc's only Provides is glibc-2.13-1.
> I like both the same-as and the Recommends idea. I don't like the
> idea of using the M-A field for same-as. There could be plugins with
> M-A:same as well as M-A:allowed semantic (e.g. a plugin enabling some
> scripting support like perl for irssi), maybe even M-A:foreign.
But only M-A:same has the problem we are trying to solve, namely: if
this module is installed on amd64 we want it to also be installed on
i386. With M-A:{allowed,foreign}, there is no question of "which
architectures", since you can only install one.
So I don't see a problem overloading the M-A header. I'd rather see
that than a second header that is only used in this one case that
always involves M-A:same.
Now the exact syntax is a bikeshedding issue. My original idea was
"M-A: same-as libfoo" but perhaps something like "M-A: same [libfoo]"
or "M-A: same: libfoo" or even "M-A: same: libc6, libc6.1, libc0.1..."
Finally, I note that this is somewhat similar to Enhances. But I don't
think it's a good idea to overload Enhances.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Reply to: