On Friday, March 23, 2012 21:45:03, jida...@jidanni.org wrote: > I have an idea, > all /etc/init.d/ script packages should test to see they actually can be > started and stopped before their debs get shipped. > Hmmm, and all bin/ programs should given a test run too... to at least > see they can print --version without segfaulting etc. > Hmmm, all even more important than piuparts. > I mean it would avoid "show stoppers of the first degree".
Servers build the packages in a chrooted jail after they're uploaded, but the chrooted jail usually doesn't have the necessary environment to actually run the programs/packages in question. Changing that to do this "quick test" would involve installing all the necessary dependencies. As a concrete example, testing the program 'kate' would involve installing a lot of KDE4 within the chroot. I suspect this would greatly slow the build process. And in general, Debian Developers/Maintainers are expected to test the programs and packages they build, so this "quick test" is already being done "client-side" rather than "server-side" before the upload. > >>>>> "AT" == Arno Töll <deb...@toell.net> writes: > AT> On 24.03.2012 01:59, jida...@jidanni.org wrote: > >> May I humbly request that your build scripts in the future "take > >> the automobile for a test drive" (/etc/init.d/apache2 start at > >> least) "at the factory, before it reaches the dealership". > > AT> And your point is? Our package worked just fine until someone else > AT> decided to break unrelated packages by uploading broken reverse > AT> dependencies exactly 8 days after uploading and building our package - > AT> or to put it with your words "after it left the factory". The proposed test would not have caught this problem, because the library is built separately from apache2, and apache2 had not been updated AFAIK. The bottom line is that even though it sounds like a reasonable idea in theory, it's probably not practical to do in practice. -- Chris -- Chris Knadle chris.kna...@coredump.us -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201203232212.10147.chris.kna...@coredump.us
