[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/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120215181932.ge2...@p12n.org