[libvirt] [PATCH 3/4] travis: test upstart script handling on precise distro scenario

Daniel P. Berrangé berrange at redhat.com
Tue Feb 27 15:19:44 UTC 2018


On Tue, Feb 27, 2018 at 04:14:21PM +0100, Andrea Bolognani wrote:
> On Fri, 2018-02-23 at 12:00 +0000, Daniel P. Berrangé wrote:
> > Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
> > ---
> >  .travis.yml | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/.travis.yml b/.travis.yml
> > index 41a293451c..0328fcb8f1 100644
> > --- a/.travis.yml
> > +++ b/.travis.yml
> > @@ -6,6 +6,8 @@ matrix:
> >    include:
> >      - compiler: gcc
> >        dist: precise
> > +      env:
> > +        - CONFIGURE_ARGS=--with-init-script=upstart
> 
> Both precise and trusty use upstart, so there's no reason not
> to apply this to both, especially if we're going trusty-only as
> suggested earlier. Limiting it to the gcc build is rather strange
> as well.

The initscript handling code is only exercised if you run 'make install'
and only the 'make distcheck' rule I added to precise will exercise
'make install'.

> Even macOS doesn't seem bothered by that at all, though it's kinda
> nasty to install an upstart init script there. Not that it would
> break anything, but it just feels wrong.

We're not running 'make install' on macOS so its a no-op :-)
 
> Perhaps we should improve our init system detection so that Ubuntu
> releases older than 16.04 and CentOS 6 will automatically choose
> upstart rather than passing this explicitly? The latter detects
> init system "redhat", and frankly I'm not quite sure what that's
> even supposed to be :)

Even though RHEL-6 supports upstart, I'm fairly sure we always
deployed RHEL-6 using traditional initscripts, not the upstart
scripts.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




More information about the libvir-list mailing list