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@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
___
Manage your subscription:
https://lists.clusterlabs.org/mailman/listinfo/developers
ClusterLabs home: https://www.clusterlabs.org/
