Re: test "/etc/init.d/MyPackage start" before shipping, please
On Friday, March 23, 2012 21:45:03, jidanni@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 <debian@toell.net> writes:
> AT> On 24.03.2012 01:59, jidanni@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.Knadle@coredump.us
Reply to: