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

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

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.


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
while the new package (built using libtool) provides
There are no packages in either the release or release-2 areas that rely on the old package.

This is odd, tho:

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


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/^\.\///'


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>)


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