This is the mail archive of the
mailing list for the Cygwin project.
Re: Packages that change without incrementing the version/release
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: cygwin-apps at cygwin dot com
- Date: Sat, 20 Nov 2004 01:22:50 -0500
- Subject: Re: Packages that change without incrementing the version/release
- References: <email@example.com>
Max Bowsher wrote:
In my latest session of setup debugging, I discovered that setup was
silently ignoring wrongly sized packages. Once I fixed that, I
discovered that I had quite a few packages that failed the check.
(Including all the xorg-x11 ones but also:
These are my packages...
Notice something? They are ALL -src packages for superseded versions of
See, when version X of gettext is released, it is a group of packages
that all share the same -src:
So, libintl1 and gettext-devel have an "external-source" line.
So, eventually, a new version of gettext changes the library API, and I
bump the version number: libintl2. So, now, we have in the main gettext
directory, newer versions of the -src package, and eventaully the
0.10.40-1 (and worse, the 0.10.40-1-src) version is pushed out.
But that's a problem, because in the gettext/libintl1/ directory, we're
still keeping the libintl1-0.10.40-1.tar.bz2 file around, for backwards
To comply with the GPL, I do the following to the "old" version of a
library when its DLL number is bumped:
(1) remove the external-source line in the old library package's
(2) copy & rename the old -src package:
cp gettext/gettext-0.10.40-1-src.tar.bz2 \
I haven't been following this discussion, so I'm not sure what setup is
complaining about. The cron job on the server is supposed to update the
md5sum -- and create a new md5sum for the "new" libintl1-....-src
package. (Does setup check the md5sum of setup.hints?)
I presume that at some point all of these have been replaced with
slightly tweaked versions without a release increment.
Not exactly, in my case (see above). It's "no -src tarball in THIS
directory" to "look, here's a -src tarball!". Now, setup.hint changed,
and setup.ini changed, but that happens all the time.
Anyway, this means many users are likely to have old 'invalid' versions
of these packages. Which means, that before I can release a new setup, I
need to make setup recover gracefully, rather than exiting at the first
error as it currently does.
Currently I'm thinking along the lines of having setup rename the
package files as it finds them, adding a ".BAD" suffix. As far as user
feedback goes, I will probably go with a MessageBox summarizing all the
problems at the end of the scan, for a short term quick hack to get a
new setup out ASAP. Later though it should become a scrollable log
I'm not sure you've actually found the reason for the error. In "my"
cases, those files were created with those names once and only once, and
were never touched again. So I don't see how the end user's cache got
"out of sync". If the local repository's setup.ini claims that package
foo has an external-src, but the newly downloaded setup.ini says it has
its own -src tarball, maybe that's the cause (of some) of the problems.