/ 2007-02-05 21:51:28 +0100 \ Andrew Beekhof: > >unless there is some other problem I am not aware of, > > > >I think it did break "make rpm" because in the begining it had > >an executable placed in /usr/sbin. I fixed that by moving it into > >/usr/lib/heartbeat. (well, the @@ define of it, anyways). > > > >now, in the meantime someone fixed the same problem by including > >that binary into the spec file. > >both "fixes" have then later been merged - which broke it again. > >there have been at least four posts about this on this list. > > > >in fact, if rasto now is able to build it against the heartbeat-dev > >packages only, and provided that this continues to work, yes, we could > >adjust our build-environment and put it into the drbd packages. > > > >but I suggest you fix the heartbeat build > > no, if linbit wants their code in our tree linbit needs to ensure it > doesn't break things.
of course. actually I fixed it once. but while adding the config and ConfigureMe option, apparently I did not proofread sufficiently and broke make rpm again, by moving that binary back to /sbin ... sorry for that. > while you're at it, can it be moved to the contrib section as > previously requested? yes. am on it now. [oh wait. I did not send this message yet. I struggled with our build environment for two hours now. will do that tomorrow.] > I've still not had a satisfactory answer as to why we need to ship > your code. There was a technical hurdle, but now things such as this > can again be built outside of our source tree so where's the benefit? from a maintenance point of view: this depends more closely on heartbeat than on drbd (though obviously you need both for it to be of any use). the interface to drbd is on the "process level": on occasion, drbd will call a handler (script, command), which is defined in the drbd.conf file. if that happens to be the provided /u/l/h/drbd-peer-outdater, that talks to this plugin dopd, and dopd on the respective "target" node will call "/sbin/drbdadm outdate $resource". if that happens to be some other mechanism, because there is some other cluster manager, or other means of communication, then so be it. technically: it does not matter one way or the other, as long as we don't need to rebuild that thing for every new heartbeat release (relevant interfaces/header files must stay binary compatible). to us, the benefit is really that we don't need to provide "heartbeat-2.0.x-contrib-drbd-peer-outdater-plugin.*" packages, because its just available with heartbeat on linux. for you, the burden is to have one extra plugin in the contrib, and build/package it by default for linux. > And (having just looked at the code), I can't say I'm thrilled to see: > #define OUTDATE_COMMAND "/sbin/drbdadm outdate" and, in any case, an additional benefit for us is, that it got reviewed by you. this particular example is a matter of taste. I dislike absolute path defines. and I don't really like a define being named COMMAND and then including the argument, expecting to be run via system(). But Rasto coded it that way, and it does not hurt in this case, either. or is there something else wrong? -- : Lars Ellenberg Tel +43-1-8178292-55 : : LINBIT Information Technologies GmbH Fax +43-1-8178292-82 : : Vivenotgasse 48, A-1120 Vienna/Europe http://www.linbit.com : _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
