Time for a new DLL release

[Parker, Ron]

> From: Chris Faylor [ mailto:cgf@cygnus.com ]

> I would like to make a new release next week but I'm not 100% sure how
> to do this.  I can put a new version of cygwin-whatever.tar.gz on the
> web site but we don't really want to have everyone download the entire
> distribution just to update cygwin.
> 
> Ideas?

I have three alternatives and as usual I am interested in opinions.

1. Create a small program that is capable of just updating cygwin1.dll and
possibly the related ".a" file for the linker.

2. Make setup update aware.

3. Write a "real" installation program.

Option 1 would be a program like setup that is essentially a self-extracting
program that would extract cygwin1.dll and copy it over the old one.  What I
am actually talking about is using MoveFileEx or the wininit.ini
functionality of Win9x.  This would allow us to replace the file on system
restart if it is in use without worrying about the user having to shutdown
all cygwin applications like inetd, etc.

Option 2 would require a bit more work.  This would involve setup keeping
track of the versions of various packages that it has installed and only
downloading/installing newer versions.  This would not manage
orphaned/renamed files that change from one release of a package to the
next.  Also we would have to develop a standard for version naming scheme or
some mechanism to determine which packages have been updated and what
"newer" really means.  See the "another question" section of
http://www.delorie.com/archives/browse.cgi?p=cygwin-developers/2000/03/20/11
:46:21 for more detail on this issue.

Option 3 is what I referred to in my original post volunteering to write a
setup program,
http://www.delorie.com/archives/browse.cgi?p=cygwin-developers/2000/02/24/15
:02:15.  This is a more long term solution and involves a port++ of RPM.  I
know RPM has been ported by many people to work with cygwin, myself
included.  What I am really talking about is not just porting it, but
creating a version that is fully integrated with the standard Windows
"Add/Remove Programs" functionality, wininet and possibly even the Microsoft
Installer event model.  Additionally it would be packaged up as a
self-extracting/installing application using some of the same code that is
used in setup.exe.  I would gladly submit these modifications to Red Hat or
whoever the maintainer of RPM is.

Any other ideas or opinions?