On 10/13/2010 1:17 PM, Vadym Chepkov wrote: > > On Oct 13, 2010, at 4:41 AM, Fabio M. Di Nitto wrote: >> >> I think the main difference is that some of those libraries are capable >> of providing services without the daemon running. Something that´s not >> true for all packages. Let´s put aside for a minute the build/linking >> case that used to be a problem many years ago, where maintaining build >> machine was expensive (tho I understand it, let´s be clear). >> > > You are saying nothing can possibly benefit from using API in provided in > -devel package > and can utilize corosynclibs on it's own without having cluster software > installed? > libraries don't provide services at all, they do provide API > >> >> I don´t remember exactly the detail here (I´d have to test it myself), >> but let´s assume we do those changes in sync, how does "yum install >> pacemaker" behave? Would pull in both corosync and heartbeat? or it will >> force the user to select one? Without repeating myself too much, default >> should install both IMHO and expert users can then drop the core they do >> not want. > > it will pull nothing and it's a more reasonable approach, admin has to decide > which stack to use. > > Lets take a bacula backup software as an example. > It provides capability to use all kind of databases as backend server - > mysql, postgresql, sqlite, > so naturally it is linked with all those libraries, but they won't force you > to install all database servers for that > or even command line clients, because all they need is a library, which will > provide API, not a "service"
There is a difference here. You can use mysql-libs to connect to a remote instance of mysql server (same for pgsql, not sure about sqlite). So in theory you can benefit from the libs API even without a local installation of mysql server. With corosync, there is no such thing. The corosynclibs need local corosync. Fabio _______________________________________________ Openais mailing list Openais@lists.linux-foundation.org https://lists.linux-foundation.org/mailman/listinfo/openais