Re: update-alternatives

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Bas van Gompel wrote:
> :  Further, since the "alternatives-wrap" program would be a cygwin prog, 
> :  it can unwrap chains of symlinks itself and exec the actual target 
> :  without using execvp().
>
> When being a cygwin program (as will be proposed) execvp will take care
> of that.

Sortof.  The reason I don't like using execvp is the 'p' at the end -- 
which implies a $PATH search.  I *know* which target I want to invoke; I 
don't want to search the $PATH for a similarly-named target that happens 
to appear in $PATH earlier.

You're right, tho, that *somebody* is going to have to walk the symlink 
chain -- either "me" (the wrap-like program) or the system (via the 
execv[p]() call).

> :  Plus, alternatives itself needs to be smart 
> :  about when to use a wrap executable, and when to use "normal" symlinks. 
> :    e.g. scripts should never be the target of a wrap, unless wrap is 
> :  smart enough to parse sh-bang headers, and exec("/bin/bash -c 
> :  real-target $@").
>
> execvp has no prblems with this. (And, the stripped (-O2) executable
> makes only 4096 bytes.)

That's interesting.

> Certainly. I'd think generally one should only wrap executables.
> (*and take real special care of dll's.*)

Yes.

> :  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. 
>
> Agreed. You might however be able to get away with just replacing the
> top link with ``wrap.exe'', writing '/etc/alternatives/' + $target to
> '/etc/wrap/' + basename($source) and having ``wrap'' (execvp) resolve
> the symlink in /etc/alternatives (for executables, noting dlls.)

Remember that alternatives is intended to be used only with cooperating 
packages.  That is, if the sendmail **maintainer** wants to 
alternativize his package, then he would:
  (1) install the binaries as /usr/bin/sendmail.sendmail

(That is, the "target" executable is installed in the original 
directory, right where the DLLs are.)

  (2) create a postinstall script that calls
       'update-alternatives --install \
        /usr/bin/sendmail sendmail ${bindir}/sendmail.sendmail 50'

This would create a text file called "sendmail" in the 
/var/lib/alternatives/ directory, describing the various possible 
targets for this "master" set.  It would also create symlinks:

  /usr/bin/sendmail -> /etc/alternatives/sendmail
and
  /etc/alternatives/sendmail -> /usr/bin/sendmail.sendmail

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

Your wrap program seems intended for a different audience: the end user 
-- who might copy the "orginal" exe away to some other directory, and 
put the wrap program in the original location -- thus leading to DLL 
search issues, as you say.

> :  I think your wrap program is a fine tool, and I'd encourage you to ITP 
> :  it (or submit it for inclusion within the cygutils package; IMO it's a 
> :  good candidate for that).  I just don't think it does, exactly, what the 
> :  alternatives package will eventually need.
>
> I'd prefer to keep this as a separate package. (This
> functionality can be used in other contexts as well.)

Fair enough.

> ITP forthcoming. (I'll need to flesh out the README, write a
> setup.hint and prepare an announcement...)
>
> I will look into creating a (new) executable to do what
> ``alternatives'' wants, as soon as I find out what format the
> links in /etc/alternatives take.

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.

--
Chuck