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

new packages


I'd like to add 2 new 'packages' to the mirror package hierarchy.

They don't need to appear in setup.ini, but I suspect that the package
scanner will add them automatically :p.

If they are marked as experimental will that suffice for preventing user
confusion?
(Oh, and what is the tag for experimental again?).

The files are:
latest/setup/setup.exe and
latest/setup/copyandspawn.exe

The reason to have them in the mirror hierarchy is that they can be
downloaded from mirrors, not just cygwin.com, and they should be in sync
with the version of setup.ini.

The reason for testing is that setting up a set of mirror hierarchies
doesn't really appeal :}.

As for what they do....
setup.exe will be the most recent released setup.exe, (possibly version
stamped in the name, but that can be address'd later), and copyandspawn
is a trivial little program that probably should be called moveandspawn.

copyandspawn 30 foo bar foo.exe waits for process 30 to quit, moves foo
on top of bar, and runs foo.exe. Setup can use this to step up to a
newer version without the user needing to manually download and recall
where they had setup.exe located. The only current hitch is that
setup.exe appears at the back of all the other windows, which IMO is a
bug - and related to the other reported window level bugs.

(yeah, trivial immediate benefit, but it's always bugged me). It should
also reduce cygwin.com traffic a little, as it will download from the
mirror site the user selected. 

The follow-on is that if setup.exe has a persistent cache directory to
store packages in, it can be placed into the cygwin /usr/bin directory,
and be run from anywhere with consistent results. Oh, and yes I've got a
patch in the wings for that too.

I'm not sure that this work should go into the first release of the
dependencies to the end users, but thats certainly an option...


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