[Cluster-devel] Building clufter on EL8

[Cluster-devel] Building clufter on EL8

[Digimer]

Hi all,

  While waiting to see what CentOS 8 will do with regard to HA, 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... I started the process of building jing myself, but very quickly
fell into a very deep dependency well.

Tips?

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

[Cluster-devel] Building clufter on EL8

[Jan Pokorný]

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: <http://listman.redhat.com/archives/cluster-devel/attachments/20191031/b06174f7/attachment.sig>