There should probably be test suites to cover dependencies to ensure that all libraries are adequately in sync -- I'm not sure how easy this is to do in practice.
Hmmm. It's best done as the library is being written because it could actually help development and because the author likely has a better idea of what a function is supposed to do. But test suites are usually ignored or built long after the fact. Since quickcheck is quite easy to use, I wonder what's missing? Is it infrastructure (a handy driver program and some make targets) or some well-worked examples to cut and paste from? Where do I find examples of how to quickly add quickcheck to my library?
BTW, Debian is unusual, in that updates happen all the time. (There are numbered releases, but they aren't commonly used, I think. They manage to make it work pretty well -- better than most others do for third party stuff, IMHO. Perhaps that model can be used?
Debian had some technical advantages in the beginning (better dependency annotations) but I understand that redhat and others have now caught up. But Debian still has a cultural advantage: packages are built, tested, debugged, etc. with the intention that people will update and install a little bit at a time rather than buying a new set of CDs and updating the entire system in one go. This puts a lot of stress on the dependency annotations which keep the system consistent but it also means that problems in the dependency annotations rapidly come to light. (I think it also means that the debian testing procedures are more rigorous but don't know for sure.) Debian does use numbered releases though. Here's a small sample of the version numbers installed on the machine I'm using just now: ii zip 2.30-5 Archiver for .zip files ii zlib1g 1.1.4-11 compression library - runtime ii zlib1g-dev 1.1.4-11 compression library - development ii zlibc 0.9j-6 Uncompressing C Library The version numbers are of the form a.b.c.d-p where a.b.c.d is whatever version number the authors use and the -p part is the version of the debian package. So, for example, the package for zip version 2.30 has been revised 5 times (perhaps fixing dependencies, adding documentation, etc.) But, Debian packages might apply patches to the software which are not included in the author's software release. These might be trivial like changing a hardwired path from /usr/local/lib to /usr/lib or they might be significant like fixing a known security hole in the Linux kernel. -- Alastair Reid