[SOLVED] - What RPM provides osgi.hsqldb.hsqldb

[TrevorH]

You will find lots of references to it. It's a big thing in the java world.

https://searchnetworking.techtarget.com/definition/OSGi

[aks]

You don't say what you are packaging - is it a jar, a war, a ear etc.?

By default (with experience) if it's (say) a jar, rpmbuild will unpack it (jars are similar to tarballs in a sense) and examine (for example if you are using maven), the pom.xml file to get a list of "requires". Also by default PM will "adjust" a "fat" jar - i.e.: change it such a way that it's not executable (the point of "fat" jars). There are macros to prevent this behaviour, but I can not recall the details at the moment.

Just put all the things (dependencies) as RPM packages in the requires. If there are not RPM packages, then you'll have to build them and add that package as a requirement.

[warron.french]

You don't say what you are packaging - is it a jar, a war, a ear etc.?

By default (with experience) if it's (say) a jar, rpmbuild will unpack it (jars are similar to tarballs in a sense) and examine (for example if you are using maven), the pom.xml file to get a list of "requires". Also by default PM will "adjust" a "fat" jar - i.e.: change it such a way that it's not executable (the point of "fat" jars). There are macros to prevent this behaviour, but I can not recall the details at the moment.

Just put all the things (dependencies) as RPM packages in the requires. If there are not RPM packages, then you'll have to build them and add that package as a requirement.

aks, that's fair. I am deliberately being cryptic; however, what I am packaging is a huge suite of software written in over 5, yes over 5, programming languages. I get it in a single tarball; and it encapsulates programs written in: bash, csh, Perl, Java, Python-2.7, Python-3.3, and C/C++.

So, the programs are all archived by the source of the archive provided to me; so I personally have no control or influence over separating out these applications based on various languages (C/C++, Perl, etc.. you get the drift). So, I am dealing with Java applications that have several jar files in their directory structures.

So, for clarity are you telling me to put an explicit Requires: tag with the string osgi(org.hsqldb.hsqldb)? That is how I am interpreting your last comment. As for what RPM package, that is precisely the problem I am running into because I cannot determine what RPM provides the feature in question.

[aks]

I get it in a single tarball; and it encapsulates programs written in: bash, csh, Perl, Java, Python-2.7, Python-3.3, and C/C++

.

Poor you. I truly sympathise.

You're probably best off splitting that tarball into different parts and saying to RPM this RPM has a (weak) dependency on the other RPMs that contain the other parts (but be careful not to have a circular dependency). Personally, I'd start with the C/C++ stuff just because the libraries involved are more likely to already be installed. Then add as you see fit (not ignoring the fact that other CentOS "parts" like YUM use python for example, so they're likely to be there too).

I personally have no control or influence over separating out these applications based on various languages (C/C++, Perl, etc.

.

Why not? Is the demand a single RPM? Boiling down engineering problem to their constituent parts is really important and that's like engineering 101. If the demand is a single RPM slap the B**ch! LOL. BTW, if you say LOL in any sentence, you can be a rude as you like, because LOL makes it all good.... and then some more LOL just to make it good.

So, for clarity are you telling me to put an explicit Requires: tag with the string osgi(org.hsqldb.hsqldb)? That is how I am interpreting your last comment. As for what RPM package, that is precisely the problem I am running into because I cannot determine what RPM provides the feature in question.

No. The string "osgi(org.hsqldb.hsqldb)" is meaningless to a package manager (package managers care about packages, not silly things like files .. nor braces for that manner - although I may be wring on the brace thing). You need to provide a copy of hsqldb.jar (I think is what file will be called, based on what has transpired above). If you need a certain version you can also way (in the SPEC file) >= <version> or the other way around.

So what package can give me this jar file? On a Fedora desktop (which is getting old mind) VM that Iḿ looking at for something else:
# dnf what provides '*hsqldb.jar'
Last metadata expiration check: 2:07:26 ago on Fri 03 May 2019 17:11:47 BST.
libreoffice-base-1:6.0.7.3-1.fc28.x86_64 : Database front-end for LibreOffice
Repo : @System
Matched from:
Other : *hsqldb.jar

libreoffice-base-1:6.0.7.3-1.fc28.x86_64 : Database front-end for LibreOffice
Repo : updates
Matched from:
Other : *hsqldb.jar

hsqldb-1:2.4.0-3.fc28.noarch : HyperSQL Database Engine
Repo : fedora
Matched from:
Other : *hsqldb.jar

hsqldb-lib-1:2.4.0-3.fc28.noarch : HyperSQL Database Engine library
Repo : fedora
Matched from:
Other : *hsqldb.jar

libreoffice-base-1:6.0.3.2-1.fc28.x86_64 : Database front-end for LibreOffice
Repo : fedora
Matched from:
Other : *hsqldb.jar

opa-fmgui-10.1.0.0-119.fc28.noarch : Intel Omni-Path Architecture Fabric Manager Graphical User Interface
Repo : fedora
Matched from:
Other : *hsqldb.jar

So you could make a "repuires" ("mandatory" in RFC speak) on libr office. That seems wrong (because libreoffice will bring other dependencies), so what's wrong with making hsqldb-lib your mandatory?

Regards

[TrevorH]

Unfortunately my experiments with the CentOS 'hsqldb' packages showed that none of its files, even inside the 3 jar files it ships, contain any references to files named "*osgi*" anything.

[warron.french]

@TrevorH, I came to the same conclusion. Thanks for looking into this.

@aks, I would love to be able to tell my source to break the suite down into separate chunks; as I described- based on languages. I have actually communicated this request to them anyway, and they were slightly receptive to the idea so in my book that's a start; however, I still have a timeline to meet now. Trust me I want to b!7ch-slap LOL the development team, but that would get me fired. I wonder if tar and feathering them would get me fired. I don't know anyone that could provide me with both resources though. Oh well.

I have determined a means, working with a cohort here, how to potentially short-circuit this dependency issue. As I am writing this email from my lab access (to the internet, to post this) I am implementing another rpmbuild with the workaround in place.

We (my cohort and I) discovered some that there are three scripts; one in Perl, the other two in Python, that check for osgi (specifically) dependencies. We modified the osgi.reqs (sp?) to simply provide an "exit 0." So far it looks like the Perl script (osgideps.pl) is being provided with the rpmbuild RPM (or is it rpm-build, oh bother) and it is not even being used by the rpmbuild binary at all.

So, we modified the osgi.reqs python script and I am testing an rpmbuild as I write this presently.

More to come.

TrevorH/aks, sincerely, thank you for the help. Have a nice weekend,

[warron.french]

The dependency for osgi(org.hsqldb.hsqldb) is being injected during the rpmbuild binary execution, which in turn executes osgi.req.

We copied that script out of the way, as a backup, and rewrote it to with exit().

Doing so allowed the script to "execute" and return with a successful return value.

Using the rpmbuild binary, which executed my version of osgi.req, prevented the injection of the requirement for osgi(org.hsqldb.hsqldb), and now the RPM actually installs my content.

This matter is now resolved.