Standards-based cluster framework Reproducible: Always
Created attachment 105993 [details] an ebuild for openais 0.80.2 Tested on amd64 and x86, sys-cluster/openais ?
Created attachment 105995 [details, diff] patch to make it work on gentoo (using env.d instead of ld.so.conf.d)
Created attachment 105997 [details] init.d script for openais
Created attachment 105999 [details] an ebuild for openais 0.80.2 Ops, meant ~amd64 not ~x86_64, only tested on ~x86 and ~amd64 (fixed KEYWORDS)
Cool, an ebuild! I think some of Red Hat's new clustering stuff uses this. Some questions and comments: *I don't think it's appropriate to do Gentoo-specific things in the Makefile (env.d). Just remove the ld.so.conf-related lines, and do the env.d stuff in the ebuild. *Are there really no dependencies? *Generally epatch is run in src_unpack(). That means your src_compile() can disappear and just use the default. Also, quote FILESDIR because it could have spaces in it. *I have a feeling that autodetecting uid/gid is at least deprecated behavior, but I haven't looked for anything documenting this.
Created attachment 106161 [details] an ebuild for aopenais 0.80.2 This quotes the FILESDIR, adds dependecies on virtual/libc (only tested it on glibc however) and move epatch into src_unpack(). The reason I keep the LIBDIR in the Makefile is that I don't want to do all of that in an ebuild. Okay, I could make a new file in the Makefile and install that, but that is even uglier (to me anyways). Didn't find anything about the uids/gids, looked up redhat to see what they use, but they had changed on an earlier occoasion (didn't find the link now) and I didn't find a gid one. I thought it might be the other way around, if we keep specific users at specific uids, we will run out sometime, if we don't we only use those that are in actual use. Also, wouldn't the whole user/uid thing be a bit of a waste if the uids were always the same .. (okay, maybe not for humans). Yeah, reason for me writing this ebuild was installing openais to get gfs2 to work, but there has been no release yet for gfs2 so I havn't bothered putting up something that uses a cvs snapshot of their code ..
Created attachment 110670 [details] ebuild for openais 0.80.2 Moves the creation of /etc/env.d/03openais into the ebuild and compiles/installs with LIBDIR overridden.
Created attachment 110671 [details, diff] patch to remove ld.so.conf.d references from the Makefile New patch to the makefile that only removes ld.so.conf.d references as the env.d/03openais is created by the ebuild.
Now, the remaining issues Donnie has with this ebuild: * uid/gid, which I don't really have any answer to, and Donnie no documentation. * dependencies: I have looked, and nothing is linked to anything other than glibc Okay, don't think there is anything left to do.. ?
Created attachment 111283 [details] ebuild for openais 0.80.2 Heh, forgot to remove some uncommented stuff, oh well.. Why do I have this feeling that this one of those ebuilds that are never going to make it into portage? :P
I suspect it will make it in as Red Hat's newer cluster stuff including GFS2 reaches maturity...
I suppose you are right, cluster-2.00.00 was just released (so was cluster-1.04.00 abit earlier btw), which means that this ebuild is actually one of the dependencies for those packages ..
Created attachment 139714 [details] /usr/local/portage/sys-cluster/openais/openais-0.82.ebuild /usr/local/portage/sys-cluster/openais/openais-0.82.ebuild
Created attachment 139716 [details] /usr/local/portage/sys-cluster/openais/files/openais-0.82-makefile.patch /usr/local/portage/sys-cluster/openais/files/openais-0.82-makefile.patch
Created attachment 139752 [details] sys-cluster/openais-0.80.3.ebuild after one night on dependency calculation, I worked out that redhat-cluster-suite in RHEL51 depends on openais-0.80.3, so here's its ebuild.
Created attachment 141052 [details, diff] Patch to change SBINDIR for use with cluster suite. The newer redhat cluster suite packages (bug #184850) all default to /sbin for SBINDIR and look for aisexec there. It makes sense to me to keep them there, so these patches just move the binaries there.
Created attachment 141053 [details, diff] fix location of aisexec, to go with openais-0.80.3.ebuild.diff
What is the condition of this ebuild and does it current reside in any overlays? Might look to put it into an overlay or tree. Likely have an immediate need for this package.
(In reply to comment #18) I'm using the openais ebuild in relationship to the ebuilds contained in the tar listed here: http://forums.gentoo.org/viewtopic-t-572129.html#4732772 It's working fine for me and is an overlay. Hope that helps.
Added 0.82 to the tree as sys-cluster/openais