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/
