Raphael Hertzog writes ("Re: authbind (LD_PRELOAD) and multiarch"):
> On Mon, 12 Dec 2011, Ian Jackson wrote:
> > * I will need to arrange for the same LD_PRELOAD setting to load the
> > correct libauthbind for each arch. So I guess I do
> > LD_PRELOAD=libauthbind.so.1 rather than supplying an absolute path,
> > and trust ld.so to get the right one out of /usr/lib/<triplet>.
> > Is that right ?
>
> I don't know, ld.so(8) does not document this. (But it doesn't look wrong
> at least)
It does seem to work.
> > * AFAICT there is no way on a multiarch system to say in my
> > dependencies "I need this package on all architectures supported on
> > this system". I went and looked at testing's fakeroot but I'm not
> > sure I should be using what it does as an example. How should an
> > LD_PRELOAD hack approach this problem ?
>
> What does fakeroot do? My first idea would be to fail early and provide a
> useful error message.
>
> Find out the arch of the executable, verify if the corresponding preload
> library is available. If it's not, then fail and instruct the user to
> install the missing library.
I'm afraid that the phrase "the executable" is not clearly defined and
may even be meaningless. fakeroot has this problem much worse, but
even with authbind you might do something like
authbind /etc/init.d/food start
Obviously it would be too much to expect the wrapper to figure out
that eventually the program which we really care about is
/usr/sbin/food and determine its architecture.
fakeroot seems to try to provide multiple libraries for some selection
of architectures in a single package. This must make building it
complicated.
Raphael Hertzog writes ("Re: authbind (LD_PRELOAD) and multiarch"):
> The wrapper depends on "libauthbind" because it's relatively useless
> without the preload library (if we want to be picky, it could be useful
> with a library of another architecture and without the library of the
> same architecture, but currently you can't depend on "libfoo:any" if
> libfoo is Multi-Arch: same).
If you are running biarch amd64/i386 then if you install the wrapper,
you want both the i386 and amd64 libraries. Having the wrapper depend
on the library means you get (only) the library of whatever arch
wrapper you happened to install.
The right dependency isn't "any". It's "all". Or really, "some
specific architecture depending on the arch of the target program
which we may not know".
Following this to its logical conclusion suggests leaving the decision
to the user who will install "libauthbind:amd64" or "libauthbind:i386"
or both.
> I don't see why the library would have to depend on the binaries (but
> maybe I misunderstood your description of the helper binaries) and in fact
> we really want to avoid the dependency loop.
The library will not work without the helper. The helper can work
without the library.
Ian.
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20198.3175.881600.523...@chiark.greenend.org.uk
