From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Pokorný Date: Thu, 31 Oct 2019 08:37:10 +0100 Subject: [Cluster-devel] Building clufter on EL8 In-Reply-To: Message-ID: <20191031073710.GC19093@redhat.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Digimer o/ On 30/10/19 16:24 -0400, Digimer wrote: > While waiting to see what CentOS 8 will do with regard to HA, you are not the only surprised here > I decided to rebuild the rhel 8 packages for our own repo[1]. To > this end, I've rebuilt all packages, except clufter. > > The clufter package relies on jing, and jing is not provided in RHEL > 8. Obviously, clufter was build for RHEL 8, so I'm curious how this was > done... Note that buildroot packages are a superset of packages available through the main channels, for various non-technical reasons, e.g. giving up on support for such. Brand new for RHEL 8 are "no support" channels like Code Ready Builder (CRB), and it might be there, or not. Frankly, I've put quite some effort to have jing (and sibling, trang) up for straightforward grab, but it was basically killed in/by the process without receiving any further support, leaving me detached altogether on these political basis. Can consider myself lucky to at least have jing in said buildroot :-/ > I started the process of building jing myself, but very quickly fell > into a very deep dependency well. > > Tips? Your options are: 1. use jing (and a very few deps, perhaps) from said CBR (if available), Fedora or older CentOS 2. edit spec file so that it skips jing-involved steps altogher; note that such measure was added only to provide additional guarantee that even if clufter itself is not updated, at least, on every rebuild (such as in various mass ones in Fedora), the newest schema from pacemaker at the time will be automatically adopted (clufter requires single-file type of schemas, whereas pacemaker is shipped with decomposed file hierarchy of these, and to that end, there is no known way to aggregate the content like this, except for some unmaintained XSL stylesheet I found back then and did not exactly trust it), but for generic use case, it shall be OK to use even older bundled versions, and as mentioned earlier, there was no allocation for clufter to catch up on various aspects of the recent development, meaning that 3.0+ schema support is on may-work basis Btw. I am a long time prononent of engaging jing validator in pacemaker itself, since libxml2 based RelaxNG schema validation is not capable of precise diagnostics, and is prone to bad performance (compared to jing, due to the nature of different approaches, I believe) for more complex documents (and/or grammars). I.e. what we have in pacemaker right now downright hurts the user experience shall there be violations in the base XML. Beside, libxml2 RelaxNG schema validation tends to be buggy to this day (just a few months back, I fixed some of these long lurking issues, but some aside regression tests effectively require jing because of that). P.S. I noticed you've sent the question also to cluster-devel beside developers at c.o ML without actually sending just a singleton, meaning I cannot reply-all conveniently, but I tried my best to cover that. -- Jan (Poki) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: