Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=511212 --- Comment #10 from Andrew Beekhof <andrew@xxxxxxxxxxx> 2009-07-26 17:13:13 EDT --- (In reply to comment #9) > ok. Finally found some time to look at this a bit. ;) Much appreciated > So, my understanding is that this is a newerversion/fork of heartbeat thats > stripped down and only has the parts pacemaker needs/wants in it. Is that > correct or am I misunderstanding? :) We're in the process of splitting the rest of the codebase. Its essentially done but just needs the sort of packaging cleanup that we're doing here before it will be made available for general consumption. I've also been on vacation a bit which slowed things down. The idea is to split the code-base into pieces based on their usage and update frequency. So essentially: heartbeat 2.1 + features + bugfixes = cluster-glue + cluster-agents + heartbeat 3.0 + pacemaker 1.0 or more recently (and relevantly for those not using the crm): heartbeat 2.99 + bugfixes = cluster-glue + cluster-agents + heartbeat 3.0 This was mentioned on the mailing list late last month: http://www.gossamer-threads.com/lists/linuxha/dev/56290 > > First, Fedora really would prefer to avoid Conflicts if at all possible. > (See https://fedoraproject.org/wiki/Packaging/Conflicts). > So, is there some way we can avoid that here? The Conflicts was only intended to be temporary. I didn't want to force a synchronized update to the heartbeat package just to get Pacemaker (and therefor cluster-glue) in. The intention from upstream is that heartbeat 3.0 (which would be the messaging and membership layer as well as the v1 resource manager) would build against cluster-glue. If/when the cluster-glue package gets approved, I would then submit an update to the Fedora's heartbeat package and we could then remove the Conflicts directive. On the other hand, if Fedora wanted to preserve heartbeat in its current pre-split state, I figured the Conflicts would (safely) allow that. > > - Can this package just rename the dirs/files that conflict with 'cluster-glue' > or something and that way they could both be installed and pacemaker could have > a compile time option to use whichever one. (Or autodetect it based on the > files found, etc). In theory this could be possible, but ideally it wouldn't be necessary since we'd have both Pacemaker and an updated Heartbeat both using cluster-glue as a common base. > > - Is using this better than using heartbeat for pacemaker? Or are they the > same? Its a subset, essentially: clplumbing + lrmd + stonith > If the same, perhaps we hold off on adding this to fedora for now, let > pacemaker use heartbeat and then down the road when enough folks have moved to > pacemaker submit this and obsolete heartbeat? I don't think that's possible, since heartbeat 2.1 conflicts massively with Pacemaker. I suspect there'd be all sorts of compiler problems, not least of all due to multiple copies of "crm" header files. > - Perhaps pacemaker could fold in the needed parts of this and just use them > internally and avoid conflict with heartbeat that way? That was considered undesirable. If we were intending to fork the code, then putting it in Pacemaker would make more sense. But that would be a last possible resort. Does that help? -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Fedora-package-review mailing list Fedora-package-review@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-package-review