This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: update-alternatives
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