update-alternatives
Bas van Gompel
cygwin-apps.buzz@bavag.tmfweb.nl
Thu Jun 30 02:17:00 GMT 2005
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
More information about the Cygwin-apps
mailing list