On Sun, Jan 23, 2011 at 11:32:07PM +0100, Thijs Kinkhorst wrote: > Hi! > > In the weekend 14-16 January 2011, the Debian Security Team convened in > Linux Hotel, Essen. We discussed many things, a lot of security work was done > and of course the necessary socialising wasn't forgotten. We'd like to thank > the Linux Hotel for again receiving us in such a great way! […] > * README.test > > Although many packages include a test suite that is run after package build, > there are packages that do not have such a suite, or not one that can be > run as part of the build process. It was proposed to standardise on a > README.test file, analogous to README.source, describing to others than the > regular maintainer how the package's functionality can properly be tested. > This is something we would like to see discussed and implemented for the > Wheezy development cycle. This is a very good idea, but I think it could be taken two steps further. These are just some ideas I have but did not explore in depth, so take them with a grain of salt. First, tests run during a package build are good, but they do not ensure, for example, that the package as installed is working OK. I've been thinking that (also) providing tests to be run after the package is installed (and not on the build results) would be most useful in ensuring that both the build process and the packaging is correct. Second, README.test are designed for human consumption, whereas a standardisation of how to invoke the tests would allow for much more automation. E.g. piuparts would not only be able to test that the install succeeds, but the automated tests also work. Of course, these would be useful only for some classes of packages, but for those they would be of much help. I have something like this in one package of mine, and it gives me a lot of confidence while doing packaging changes. thanks, iustin
Attachment:
signature.asc
Description: Digital signature