Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> Goswin von Brederlow writes ("Re: Multi-arch all-architecture plugins"):
>> As you said these are usualy plugins that nothing depends on. So this
>> wouldn't help much. Also if there is a dependency than the rules for
>> m-a:same should be sufficient. If the package is something to depend on
>> then packages of all architectures should depend on it if they use
>> it. The plugin might only be used by amd64 packages and none of the i386
>> would depend on it and then installing only amd64 is perfectly fine.
>
> I don't think that's the case. Consider something like fakeroot. The
> fakeroot binary itself may be any architecture, because its function
> is to set up a socket and be a server for children and set an
> LD_PRELOAD and so forth. But the libfakeroot.so must be available for
> all configured architectures so that the LD_PRELOAD works no matter
> what architecture(s') binaries end up running.
Ok, this is a 3rd class of packages with this problem. libfakeroot.so
isn't a plugin but due to LD_PRELOAD it has the same issues with
multiarch as plugins with no depends on them (e.g. input methods).
> So you would have:
>
> Package: fakeroot
> Multi-Arch: foreign
> Depends: libfakeroot
>
> Package: libfakeroot
> Multi-Arch: all
>
> and it would have to mean "install libfakeroot for all configured
> architectures". If libfakeroot were m-a:same then it would mean
> "install libfakeroot for the arch whose fakeroot we picked" which is
> wrong.
>
>> I would concentrate on the case that nothing depends on it and the
>> solution while keeping the depending case in the back of my mind.
> ...
>> Another possible solution was to have a metapackage with wildcard
>> dependency:
>>
>> Package: plugin-all
>> Depends: plugin:*
>
> So plugin would be m-a:allowed ?
No limitations on what plugin may be, doesn't factor into the equation
so far. For fakeroot it would be this:
Package: fakeroot
Multi-Arch: foreign
Depends: libfakeroot:*
Package: libfakeroot
Multi-Arch: same
>> One thing to keep in mind is that the list of architectures for the
>> system might change (the admin adds another architecture) making any
>> such all-archs dependencies suddenly unfullfilled. But that is probably
>> unavoidable and apt-get -f install would fix it right up.
>
> Yes. Something would have to be done then, certainly.
>
> Perhaps the right answer is not to consider configured architectures,
> but rather architectures for which any package is installed.
>
> Ie, as follows:
>
> * Find the set of all architectures "foo" for which any package is
> present on the system
>
> * Now for each
>
> Package: plugin
> Architecture: bar
> Multi-Arch: all
>
> imagine a dependency
>
> Depends: plugin:foo1, plugin:foo2, ...
>
> Should dpkg do this as well as apt ?
>
> Ian.
Good question. Apt certainly has to care. dpkg could ignore it and
assume frontends will do the right thing.
MfG
Goswin
--
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/87d39gtgo0.fsf@frosties.localnet
