update-alternatives

[Charles Wilson]

Igor Pechtchanski wrote:

> 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?

hoo boy.  thinking about wrapping dlls makes my hair bleed.  I'm gonna 
pretend this was never mentioned. :-)

> 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?

Actually, I was kinda thinking about something like this:

    $ ls /usr/bin
      ...
    /usr/bin/my-app.from-package-1.exe
    /usr/bin/my-app.from-package-2.exe
      ...

    $ cp alternatives-wrap.exe /usr/bin/my-app.exe
    $ ln -fs /usr/bin/my-app.from-package-1.exe /etc/alternatives/my-app
    $ ln -fs /etc/alternatives/my-app '/usr/bin/.##wrap##my-app'

Obviously, those last three commands would actually be handled by the 
update-alternatives program, and not done manually.  Also, it'd  be a 
little different if the ultimate target were a script instead of a 
binary executable.

The idea would be that the alternatives-wrap.exe binary would "know" to 
look in its current directory for a symlink with the name 
.##wrap##XXXXXX, where XXXXXX is argv[0] stripped of its .exe extension 
and path.

This avoids one issue with Bas' one-directory-to-wrap-them-all approach: 
what if you have two different (but identically-named) binaries which 
live in different directories, and you want to wrap them both?  (Yes, 
it's a pathological corner case ["WHY would you ever want to do that?"] 
-- but somebody, somewhere, will try it -- and the results would be 
confusing to say the least, under Bas' implementation).

> 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.

That's a really good idea, for inclusion with the "main" wrap program 
that Bas is proposing.  The workalike for use by alternatives doesn't 
need one; update-alternatives itself would be the only "authorized" 
manipulator of alternatives-wrap and associated files/databases.

--
Chuck