update-alternatives

[Igor Pechtchanski]

On Thu, 30 Jun 2005, Bas van Gompel wrote:

> Sorry for the slow reply...
>
> Op Mon, 27 Jun 2005 00:17:01 -0400 schreef Charles Wilson:
> :  Bas van Gompel wrote:
> [Re-adding attribution:]
> + > Charles Wilson:
> [...]
> : > :  without using execvp().
> [...]
> : > :  Plus, alternatives itself needs to be smart
> : > :  about when to use a wrap executable, and when to use "normal" symlinks.
> [...]
> : > Certainly. I'd think generally one should only wrap executables.
> : > (*and take real special care of dll's.*)
> :
> :  Yes.
>
> What I meant to say was: ``Special care should be taken *not* to wrap
> DLLs, although they appear as executables in the file-system.''

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?

> : > :  So, (a) alternatives isn't set up, YET, to use any sort of wrap prog,
> : > :  and (b) when it is, it probably shouldn't use your wrap, directly.
> [how ``alternatives'' works]
>
> :  update-alternatives manages the symlinks in /usr/bin AND the symlinks in
> :  /etc/alternatives/.  Under a wrap scenario, update-alternatives would
> :  need to know (sometimes) to make the item in /usr/bin be a wrap
> :  executable, pointing to the appropriate /etc/alternatives/ "target"
> :  symlink, which in turns points back to /usr/bin/...
>
> 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'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...

> When I have resolved FHS-issues...
>
> (I'm going for "${libdir}/wrap/" to store the binaries, "${bindir}/"
> for the install-scripts, pointerfiles/links go in ${sysconfdir}/wrap
> and ${sysconfdir}/alternatives, respectively, for now.
>
> Preliminary binary package file-list:
>
> /usr/bin/wrap
> /usr/bin/wrap-alternative
> /usr/lib/wrap/wrap.bin
> /usr/lib/wrap/wrap-alternative.bin
> /usr/share/doc/wrap-1.0/AUTHORS
> /usr/share/doc/wrap-1.0/ChangeLog
> /usr/share/doc/wrap-1.0/COPYING
> /usr/share/doc/wrap-1.0/INSTALL
> /usr/share/doc/wrap-1.0/NEWS
> /usr/share/doc/wrap-1.0/README
> /usr/share/doc/Cygwin/wrap-1.0.README
>
> 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.

> ...and have thought over info/man-pages, the ITP will follow,

HTH,
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT