This is the mail archive of the 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: Packages that change without incrementing the version/release

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 libraries.

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 compatibility.

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 setup.hint
(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 textfield.


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.


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