Re: [HEADSUP] Let's start a Cygwin 1.7 release area

[Charles Wilson <cygwin at cwilson dot fastmail dot fm>]

Christopher Faylor wrote:
> I think the simplest thing to do is remove the test from setup.hint.  It's
> all test anyway.  Anyone who is using this should be extremely aware of
> the fact that it's unstable.

OK.

Changes I made in the release-2 area:

1) inetutils: made test release 1.5-3 current

2) libtool: made test release 2.2.2-2 current; removed versioned 
requires (made global). Removed libltdl3 from requires.

3) libltdl3: copied over old libtool-1.5.27a-1-src package as 
libltdl3-1.5.27a-1-src, and removed external-source: line from 
libltdl3's setup.hint.

4) login: made test release 1.9-8 current

5) pkg-config: made test release 0.23a-1 current

6) rxvt: removed reference to non-existent prev: version

7) tcp_wrappers: removed reference to non-existent prev: version, and 
versioned requires (made global).
7a) libwrap0: removed versioned requires (made global).
7b) libwrap-devel: removed versioned requires (made global).


I did not remove the xpm-nox package, but maybe we should. It has been 
superseded by the libXpm-noX package for years. The old package provides
   cygXpm-noX4.dll
while the new package (built using libtool) provides
   cygXpm-noX-4.dll
There are no packages in either the release or release-2 areas that rely 
on the old package.

This is odd, tho:

$ pwd
.../pub/cygwin/release
$ find . -name "setup.hint" | grep libXpm-noX
./libXpm-noX/setup.hint
./libXpm-noX/libXpm-noX-devel/setup.hint
./libXpm-noX/libXpm-noX_4/setup.hint
$ cd ../release-2
$ pwd
.../pub/cygwin/release-2
$ find . -name "setup.hint" | grep libXpm-noX
$ ls libXpm-noX/setup.hint
libXpm-noX/setup.hint
$ ls libXpm-noX/libXpm-noX-devel/setup.hint
libXpm-noX/libXpm-noX-devel/setup.hint
$ ls libXpm-noX/libXpm-noX_4/setup.hint
libXpm-noX/libXpm-noX_4/setup.hint

Huh?


Here's a list of setup.hint files in the release-2 area that have test:, 
priv:, or curr: specifiers -- but given the weirdness above, I'm not 
sure it is comprehensive.

$ find . -name "setup.hint" |\
   xargs grep -l -E 'test:|curr:|prev:' |\
   sort | uniq | sed -e 's/^\.\///'

emacs/emacs-el/setup.hint
emacs/emacs-X11/setup.hint
emacs/setup.hint
gdb/setup.hint
grace/setup.hint
postgresql/libecpg-compat2/setup.hint
postgresql/libpq3/setup.hint
postgresql/setup.hint
xemacs/setup.hint
xemacs/xemacs-emacs-common/setup.hint
xemacs/xemacs-tags/setup.hint

> Apparently there is a bug in this version of unionfs, though.  If you
> try to recreate a missing file by just copying it in or touching it you
> get a "File exists" error and that's not right.  You aren't supposed to
> have to know that there is something special going on and a mysterious
> error like that sort of breaks that assumption.

So how does this work in the future? If I have upload a new package to 
the (old) release area, it will also appear in the release-2 area?

If I edit the setup.hint in the (old) release area, those changes will 
show up in the release-2 area, UNLESS I or someone else has already 
modified the release-2 setup.hint?

(and don't delete anything from the release-2 area unless you're really 
really sure you'll never want to put it back <g>)

--
Chuck