This is the mail archive of the cygwin 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]

Conjoining Setup & CygWine & Some Other Requirements. Was: Re: CygWine 1.0 Beta -- an new cygwin package manager

I found Brant & Warren Young and Dave Korn, et al's comments
about a possible conjoined 'setup', and the unfortunately
named (& soon to be renamed -- TYVM), 'cygwine', and the
requirements thereto (;-)), to be right to the point.

I would like to suggest two new features for the
setup/command line. The specification of an initial user-
defined script (filename) that gets executed prior to
getting into the meat of 'setup', and one that executes

* The purpose of the initial script could be to (among other
 things) save some configuration info before running setup,
 > Look to see if there is a newer 'setup.exe' that takes
   precedence over the one you are using
 > Saving the registry
 > On Vista, a recovery point.
 > Running mount -m and saving to a script file.
 > It doesn't even matter that Cygwin doesn't really impose
   any risk, it just creates a good excuse to save
   Windows/the user (e.g., me) from it-/his-/her-self.
 > Saving .../bin, etc. directory lists for later diffs.
 > Storage consumed by the /... tree, before update
 > ...

* The purpose of the concluding script could be to (among
 other things)
 > Run 'makewhatis' to update the 'whatis'/'apropos'
 > Locate updated documentation: 'man', 'info', HTML, FAQs,
   README, etc.
 > Creating PDF documents out of select new 'man', 'info', HTML
   and text documents.
 > Create pseudo 'man' pages of 'info' trees using some of
   the 'info' command line dump options.
 > Computing diffs on .../bin, etc directory lists.
 > Storage consumed by the /... tree, after update.
 > View the setup log file, automatically
 > Download the latest OLOCA so "you" can be as hip as
   the Cygwin movers and shakers ;-)
 > ...

Now, you could run setup from within a script in order to
invoke the initial and final scripts but this would create
conflicts with installs of busy components caused by the


P.S. I volunteer, in advance, to write/organize/format/
    whats-ever-required in/of/by/to/from the
    documentation, if anyone is interested, starting with
    the current 'setup' update effort and spanning through
    the conjoined effort.

-- Unsubscribe info: Problem reports: Documentation: FAQ:

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