Packages that change without incrementing the version/release

[Charles Wilson]

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

> bzip2/libbz2_0/libbz2_0-1.0.2-1-src.tar.bz2
> gettext/libintl/libintl-0.10.38-3-src.tar.bz2
> gettext/libintl1/libintl1-0.10.40-1-src.tar.bz2
> libpng/libpng2/libpng2-1.0.12-1-src.tar.bz2
> ncurses/libncurses5/libncurses5-5.2-1-src.tar.bz2
> ncurses/libncurses6/libncurses6-5.2-8-src.tar.bz2

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:

gettext-0.10.40-1.tar.bz2
gettext-devel-0.10.40-1.tar.bz2
gettext-0.10.40-1-src.tar.bz2
libintl1-0.10.40-1.tar.bz2

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 \
            gettext/libintl1/libintl1-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.

true.

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

--
Chuck