On 10/13/2010 11:42 AM, Vladislav Bogdanov wrote: > 13.10.2010 11:41, Fabio M. Di Nitto wrote: > ... >>> It is absolutely legal to have both heartbeat and corosync packages >>> installed even with that "Provides: cluster-engine" virtual dependencies >>> as long as they do not have "Conflicts:" or "Obsoletes:" on each other >>> or some filesystem-level conflicts. >>> So, each of them could be added later (or removed as long as another >>> remains installed). >> >> 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. > > Just tested on dummy packages. > yum decided to install cluster engine which has a "greater" name > (although this can be a wrong assumption). > I can attach rpm specs if you are interested in them (cleng1 and cleng2 > are identical "cluster engines"). > > ====== > # yum install crm > Setting up Install Process > Resolving Dependencies > --> Running transaction check > ---> Package crm.x86_64 0:0.0.1-1.fc13 set to be installed > --> Processing Dependency: crm-libs = 0.0.1-1.fc13 for package: > crm-0.0.1-1.fc13.x86_64 > --> Processing Dependency: cluster-engine for package: > crm-0.0.1-1.fc13.x86_64 > --> Processing Dependency: cleng2-libs for package: crm-0.0.1-1.fc13.x86_64 > --> Processing Dependency: cleng1-libs for package: crm-0.0.1-1.fc13.x86_64 > --> Running transaction check > ---> Package cleng1-libs.x86_64 0:0.0.1-1.fc13 set to be installed > ---> Package cleng2.x86_64 0:0.0.1-1.fc13 set to be installed > ---> Package cleng2-libs.x86_64 0:0.0.1-1.fc13 set to be installed > ---> Package crm-libs.x86_64 0:0.0.1-1.fc13 set to be installed > --> Finished Dependency Resolution > > Dependencies Resolved > ======
Thanks for taking the time to test this. My only objection to this approach becomes purely "political" as it is going to create some controversial debates on which engine should have the "greater" name tho. And truth told, I really don´t think it´s worth the discussion. My position is "let´s give both to users and let them decide what they want", rather than having to listen to different complains on which one should be best.. I am sure you know what I mean. Let´s wait anyway for Tom to come back to us for an extra external opinion. Fabio _______________________________________________ Openais mailing list [email protected] https://lists.linux-foundation.org/mailman/listinfo/openais
