Cygwin Setup.exe future - Mailing list pgsql-hackers

Dear all,

Here is a copy of a mail received from
"Robert Collins" <robert.collins@itdomain.com.au>.

Jean-Michel POURE

> -----Original Message-----
> From: Jean-Michel POURE [mailto:jm.poure@freesurf.fr]
> Sent: Friday, May 10, 2002 6:30 PM
>
> Does setup.exe support uninstalling just like rpm -e package
> name does? Are
> dependencies taken into account during uninstall?

Not currently, but it should. It will for the cygwin project eventually.
> Is Cygwin listed in each package dependency?

No, as I said - it's optional (because cygwin itself is in base). As we
are talking about the use of the codebase for debian, it doesn't really
matter what the cygwin setup.ini files contain though.
> OK then. If I only want ot install PostgreSQL, it will only
> download the
> required dependencies, right? Does the installer check
> version dependency?

It only downloads whats needed for what you install. i.e. If you install
(say) ncurses, it will download libncurses automatically. And
dependencies are transitive. If A requires B, and B requires C. A does
not need to list C unless A is directly dependent on C. Setup will 'do
the right thing'.
Not currently, it's on the todo, as is 'provides:'.
> > Why do you say setup.exe is horrible? Bad architecture? Bad GUI?
> > Doesn't work? The last two days of MD5 related errors that
> I have not
> > had time to look at?
>
> Bad GUI for sure.
>
> 1) There should be a small descrition of each package like in
> .DEB or .RPM
> packages. A single line is not enought. A Windows user does
> not know what he
> is downloading.

We want to put popups when you mouse over the packages. Also we want
more keyboard control, to assist partially disabled (or whatever the
politically correct discription is) users.
> 2) Packages should be listed in an on-line database. With a
> full description
> and manuals.

http://www.cygwin.com/packages. However, because setup.ini, like the
debian Packages database is federated, this cannot be a complete list,
only a list of the cygwin-ditribution's packages.
> 3) Cygwin installer should be accessible in the Control Panel
> directly or in
> Add/Remove software. Presently, it can only be access through
> the setup.exe

There's no reason that it can't be. It'd only take a few registry
entries. I've added this to the TODO list. However, the user would have
to choose when to register setup.exe, because if the user chooses 'run
from net' you wouldn't want the temporary copy of setup.exe to be
registered with Add/Remove.
> 4) We need a setup.exe command line tool to implement limited
> installers that
> will not conflict with setup.exe. Example : if we release a
> limited Cygwin
> installer at PostgreSQL, we need to be sure it will not
> conflict with Cygwin.

The setup.exe code base in HEAD is being heavily modified for reuse.
It's been a long term goal to make setup.exe's code available without a
full fork() being made of the code base. The first tool to appear will
be a setup.ini linter, similar to lintian, which will use the setup.ini
parser, but nothing else. The code is in C++, and is slowly becoming
clean. (It started off life as a sort-of C++ using C methodology
project, and that made it very hard to change.)
> What is the on-going work as for setup.exe? Could you
> describe shortly what is
> in the hub ?

The cygwin-apps@cygwin.com mailing list is the best place to discuss
setup.exe. I think it's a little off-topic.

Suffice to say, setup.exe is not a trivial application, and while a
minimal version can be created quite easily, I really believe that
contributing to/leveraging setup.exe will be much more time-effective.

Rob

Current WISHLIST and TODO's from CVS follow:

(Some of these have been done, but not tested enough to remove from the
list).

TODO:

* Chooser dialog needs work.
* Mirrors list orer is snafued.
* Don't downgrade if the curr version is <= installed?
* support rpm/deb files for reading the package from. (To allow the
maintainers
the use of rpm/deb tools to create packages.) * make a librar(y|ies) for setup and cygcheck to use containing 1)
Somethingto translate POSIX -> native.  Currently called "cygpath"    in setup, although this is probably a bad choice
ofname. 2) Something to return the list of installed packages. 3) Something to return the cygwin mount table.
Currently,I have 
implemented    a lightweight setmntent and getmntent using the code in 4) Something to parse a tar file name into
package/versionor 
altenatively,    return that information from 2) 5) Something to return a list of files associated with a package.
* When installing and enough packages default to visible, the RH
scrollbar is sometimes hidden.
* Mark versions as prev/curr/test in the GUI when clicking through them.
* Remove *empty* directories on uninstalls
* Correctly overwrite -r--r--r-- files.
* Make setup.exe available through Add/Remove

WISHLIST: *  rsync:// support *  Some way to download *all* the source *  When clicking on a category that is showing a
partiallist (auto 
added item
s due to dependencies) show the full list rather than minising. *   incremental/recoverable download capability. *
build-depends*   FTP control connections should be closed when we are awaiting user 
input. *   Show a sdesc for each category * Add friendly error reporting to simpsock.cc * scan newly installed files
forREADME files, show list to user, let 
them rea
d them if they want.  * Mouse wheel support broken/missing for *some* users.  * When in category view, and changing
fromprev->normal->exp the 
categories g
et collapsed This is non-intuitive.  * mirrors.lst to be copied to setup.ini and cached locally. Then the
master m
irrors list is reserved for bootstrapping.  * clicking on a package that is in multiple categories should update
the viewof the package in both locations on screen. - Done?  * remember the view mode - ie if you leave setup in
partial,it 
returns to pa
rtial automatically.  * new view - "action / category / package"  * Downloading from the internet should be _able_ to
listbased on 
what is pre
sent in the cache, as opposed to what is installed. (To help building a
completeinstall set for a different machine).  * new view - show installed packages only. Probably not categorised.  *
newview - show non installed packages only. - Have an option to display any downloaded READMEs (or at least 
mention that they exist) - Don't ask about the start menu or desktop options if they already
exist  * Save the manual proxy settings so they don't need to be retyped.  * detect files in mulitple packages  * save
alloptions  * run a different script after finishing setup.  * Show bin and src download size  * Set ntsec permissions
correctly,and for new installs enable ntsec.