Re: update-alternatives

[Bas van Gompel <cygwin-apps dot buzz at bavag dot tmfweb dot nl>]

Op Wed, 29 Jun 2005 22:32:17 -0400 (EDT) schreef Igor Pechtchanski
in <Pine.GSO.4.61.0506292219060.15060@slinky.cs.nyu.edu>:
:  On Thu, 30 Jun 2005, Bas van Gompel wrote:
[...]
: > Op Mon, 27 Jun 2005 00:17:01 -0400 schreef Charles Wilson:
: > :  Bas van Gompel wrote:
: > [Re-adding attribution:]
: > + > Charles Wilson:
[``wrap'' *not* to wrap DLLs.]
:
:  Umm, why not?  I mean, the mechanism for wrapping DLLs is very different
:  than that of wrapping executables (and much more involved), but isn't
:  there a possibility of writing a "wrapdll.dll" that looks up the name of
:  the DLL in the /etc/alternatives database, dlopen's it, and emulates all
:  of its functions somehow?  ISTR something like this done in my OS class
:  ages ago, but don't recall the exact details.  Am I misremembering?

I Don't see how this could work. ``Statically'' linked, the wrapper's
``exports''-table would be consulted, would it not?

I can imagine building a custom wrapper-dll for each wrappee, using an
autoload-like method, but don't intend to investigate further, for now.

Wouldn't this kind of thing be easier to address from the context of
``libtool'', in each DLL's build-system?

So far, I can envision this working (reasonably) only when making
gcc/binutils a run-time requirement of ``wrap'', or having a topheavy
(dll-analyzing/building) installer, both of which I'd prefer not to.

[how ``alternatives'' works]

: > Yes. I have since seen that ``alternatives'' uses a pure ``C'' approach,
: > so my shell-script installers might not be appropriate. It should not be
: > hard for ``alternatives'' to copy the wrapper bin-file itself, however.
:
:  I wonder if these could be "real" symlink approximations, i.e., the path
:  to the executable to run would sit in some static string at a known
:  offset, and the installer could simply write into the executable at that
:  offset?  Or is this too much?

I guess this could be done... Nice idea. I will look into it.
Thanks.
There is probably a CRC to contend with somewhere.

: > :  I'm not sure it's worth your time to do so right now.  I think the
: > :  /bin/ash vs. /bin/bash thing will be resolved some other way, and that's
: > :  the only pressing need for an MSWin-friendly symlink-wrap-thingy from
: > :  the perspective of update-alternatives.
: >
: > I did since however write a ``wrap-alternative'' executable, which uses
: > execv... Not having to read a file makes it even simpler than the
: > ``wrap'' executable. :)
:
:  That actually sounds like what I mentioned above...

It isn't, however. The link is read from ${sysconfdir} + "/alternatives/" +
basename(argv[0])''

[FHS-issues]
: > Preliminary binary package file-list:
: >
: > /usr/bin/wrap
: > /usr/bin/wrap-alternative
: > /usr/lib/wrap/wrap.bin
: > /usr/lib/wrap/wrap-alternative.bin
[...]

: > Any comments?)
:
:  Looks good.  You could also provide a "create-wrap" script/program, that
:  would have "ln -s" semantics and create a wrapped executable (and it could
:  also check that the thing you're wrapping *is* an executable, and not,
:  say, a DLL).  That way, if you decide to switch the implementation later,
:  the scripts that create wrapped executables won't have to change.

In the above, /usr/bin/wrap and /usr/bin/wrap-alternative are the
scripts you suggest (No checking for DLLs (or non-executables for that
matter) yet, though). I should rename them I guess. It's confusing
already. create-wrap? install-wrap? mkwrap?

:  HTH,

It does, thanks.


L8r,

Buzz.
-- 
  ) |  | ---/ ---/  Yes, this | This message consists of true | I do not
--  |  |   /    /   really is |   and false bits entirely.    | mail for
  ) |  |  /    /    a 72 by 4 +-------------------------------+ any1 but
--  \--| /--- /---  .sigfile. |   |perl -pe "s.u(z)\1.as."    | me. 4^re