[ClusterLabs Developers] Building clufter on EL8

[Digimer]

On 2019-10-31 3:37 a.m., Jan Pokorný wrote:
> 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

Not being a very good packager, I've never really gotten a good handle
on buildroot. With all the competing pressures with development of the
Anvil!, I can't really justify the time to learn it until at least next
summer. So for now, this option is beyond me, I think.

> 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

I tried grabbing jing from F29, but that depended on;
* bsh
* isorelax
* javacc
* qdox
* relaxngDatatype
* relaxngDatatype-javadoc
* testng
* xalan-j2
* xerces-j2
* xml-commons-resolver

None of which are in RHEL8. So I tried to build 'bsh', but that depends on;

* ImageMagick
* bsf
* glassfish-servlet-api
* javacc
* javapackages-local
* junit

Again, none of which are in RHEL8. This is where I realized I was
sliding off a cliff, as I hadn't even gotten to the java stuff...

> 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).

How feasible would it be to add a '--without jing' conditional to the
clufter.spec? It sounds like jing is needed, but you also mention "edit
spec file so that it skips jing-involved steps all together". If it's
feasible, having this switch would make it a lot easier to maintain the
package until/unless CentOS 8 adds support for it.

> 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.

Ya, that was a goof on my part. I assumed that list was dead, which is
why I basically ignored it and resent it here (and why I'm dropping it
off this reply).

-- 
Digimer
Papers and Projects: https://alteeve.com/w/
"I am, somehow, less interested in the weight and convolutions of
Einstein’s brain than in the near certainty that people of equal talent
have lived and died in cotton fields and sweatshops." - Stephen Jay Gould