Re: update-alternatives

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

Sorry for the slow reply...

Op Mon, 27 Jun 2005 00:17:01 -0400 schreef Charles Wilson
in <42BF7DBD.9030908@cwilson.fastmail.fm>:
:  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.''

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

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

It's more intended for when a package uses a symlink to an executable,
and you want to use the program from outside of cygwin.

(e.g. unison.exe being replaced with a(n ``alternatives'') symlink, as
multiple versions became supported or to have a ``rbash'', ``egrep'',
``fgrep'' etc. which can be invoked from windows, without having
to resort to hardlinks/copying.)

I never intended to say anything about DLL search issues. :]

[...]

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

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


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


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


L8r,

Buzz. [If this is too OT do feel free to TITTTL, I read there as well.]

BTW: The ``alternatives'' man-page points to a ``Red Hat'' bugzilla,
and mentions a copyright by them. Is that as should be?
-- 
  ) |  | ---/ ---/  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