David Lee wrote:
> 
> To set the ball rolling, I suggest something like:
> 
>  o While these projects are chiefly focussed on Linux, we try to make
>    reasonable efforts for them to work on other major OSes, both
>    commercial (Solaris, HPUX, etc.) and free (*BSD).
Something which may be helped by your next two suggestions...
> 
>  o Overall try to follow GNU Coding Standards where reasonably possible.
>    Put another way, if our code deviates from GCS then we should be able
>    to provide a decent rationale.
> 
>  o Require 'gcc'.  (For example, my attempt earlier this year to get a
>    clean compile from Sun's compiler was a step too far.)
> 
For the last x years I've always tried to use gcc on Solaris, either by getting 
it from sunfreeware or by building it.
Whenever I've tried using Sun's compiler I've hit problems.  By requiring gcc 
and gmake (and certain minimum versions)
we can "level the playing field" somewhat.

>  o What minimum of version of 'gcc'?  For instance, Solaris has 3.4.x
>    readily available via the CSW respository.  Other OSes might have
>    other constraints: anyone know of any?
> 
>  o Require Gnu/make.  It would be nice to allow vendor-make, but there is
>    so much variability, and, given our need to have additional software
>    anyway (e.g. gcc, libnet, ...), saying GNU/make seems straightforward.

In a previous post I mentioned a wiki page. Those familiar with EMC will know 
that they have a "compatibility matrix"
which is basically where they certify that SAN product A will work with O/S B 
on hardware C etc.

Unless I've missed something somewhere there isn't a similar table/matrix for 
Heartbeat and/or Pacemaker. What I have in
mind is something where newcomers can check to see if their intended 
combination of Heartbeat (or openAIS), Pacemaker,
compiler (environment), O/S and architecture (SPARC, x86/64, PPC) has been used 
before successfully and any pitfalls to
watch out for.

It's obviously not possible for the core developers to test on every 
conceivable combination, which is where users "out
there" come in. Experienced (registered?) users would maybe be able to submit 
details of new combinations that have
worked for them.

>  o Installation locations.  GNU tends to default to "/usr/local/bin" (and
>    equivalent locations).  We (rightly) need to install in the native-OS
>    locations.  (That's the rationale for the coding currently inside
>    "ConfigureMe" and some of "configure".)
> 
>  o Scripts (e.g. RAs) ought to be in commonly available languages, shells,
>    etc.  Any "#!/bin/xxx" must be accurate.  In other words a "#/bin/sh"
>    must not contain Bash-isms, but a "#!/bin/bash" may make full use of
>    'bash' features.  Libraries of 'sh' functions ought to be available to
>    any sh-like variant, and so should be kept Bourne-compliant.
Something that "bit" me on Solaris - the startup script placed in /etc/init.d 
wouldn't work, until I changed it to
#!/usr/bin/bash

> 
> How does that sound for starters?
> 

Get's my vote! :)

-- 
Paul Walsh
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

Reply via email to