This is the mail archive of the cygwin-apps@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: update-alternatives


[I'm reformatting some of your lines, to be able to answer points
individually.]

Op Sun, 26 Jun 2005 19:12:00 -0400 schreef Charles Wilson
in <42BF3640.1090904@cwilson.fastmail.fm>:
:  Buzz wrote:
[A ``wrap'' executable.]

:  I think it's a neat idea, but I don't think update-alternatives should 
:  use it.  I plan to, eventually, borrow some of the ideas you mention and 
:  integrate them into a similar program distributed as part of the 
:  alternatives package.

I understand, in the long run, st. like that could evolve.

:  The reason I'm planning to do it that way rather 
:  than use your version directly, is because I don't want the 
:  "alternatives" package to have to manage TWO different databases. 

That makes sense. So let it be a separate package.

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

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

:  Regardless, sometimes you want alternatives to swap 
:  out man pages and such, and alternatives would definitely need to know 
:  NOT to use a wrap proggie in those cases.

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

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

:  Worse, I'll need to come up with some extension to the database language 
:  used in /var/lib/alternatives/*, or add mucho smarts to 
:  update-alternatives, before even considering to use any wrap prog.

One more reason to delegate this to another package.

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

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 can't seem to download your packages. My local ftp appears to be
borked. For this once, could you mail me your -src file?]


L8r,

Buzz. [What's with the trailing spaces?]
-- 
  ) |  | ---/ ---/  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]