[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Multi-arch all-architecture plugins

Ian Jackson <ijackson@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.


Reply to: