I wish they hadn't split and bundled, we'll have to tweak the build system of pycatch22 to use the shared object too.

I worry about us providing a general shared object a little. It isn't clear to me if upstream intends this, and if they don't they also dont worry about soname versions and ABI stability. Us providing a versioned shared object may indicate to downstream users that it is meant to be developed against etc.

Is it worth speaking to upstream about this, do you think?

A "middle path" could be to generate the soname but keep the version at 0, and keep it in a /usr/lib/catch22/.. folder to indicate that it's a private shared object? That'll still allow us to use it for the pycatch22 package, but it'll prevent others from using it as a public shared object to develop against?

(I may not be making sense here, please do let me know if that's the case :D)

I worry about us providing a general shared object a little. It isn't clear to me if upstream intends this, and if they don't they also dont worry about soname versions and ABI stability. Us providing a versioned shared object may indicate to downstream users that it is meant to be developed against etc.

That’s fair. As you might remember, upstream provides no build system at all, just a comment in the documentation about feeding all the sources to GCC.

Is it worth speaking to upstream about this, do you think?

Maybe. Trying to persuade them to usefully organize the code as a library would be a public service, although I’m not quite sure if I’m feeling up to tackling it right now.

A "middle path" could be to generate the soname but keep the version at 0, and keep it in a /usr/lib/catch22/.. folder to indicate that it's a private shared object? That'll still allow us to use it for the pycatch22 package, but it'll prevent others from using it as a public shared object to develop against?

Note that the .so version here is 0.1 in accordance with the downstream .so versioning guidelines, not just 1.

However, the suggestion of building as a “private” library is not a bad one.

Another possibility is to throw up our hands and say that upstream doesn’t even build catch22 as a library, so we can’t be expected to unbundle it. That’s a valid approach.

We have some time to think it over. Let me know how your thoughts develop.

I opened a ticket upstream:

https://github.com/DynamicsAndNeuralSystems/catch22/issues/29

we can wait a few days to see what they say and then see what we want to do

This is what upstream said:

Thanks for the input and interest in the package. Yes, we thought it was cleaner to separate out
the R, python, and Julia wrappers into their own repos. We are not proficient in managing shared 
libraries, and for use in python are supporting installation as pycatch22 via pip.

If I understand correctly, there is elegance in the shared library solution in maintaining the C in a 
single place, but given we are not proficient in managing it and don't anticipate changes to it, were 
planning to go with the less elegant solution [in the case of any change being required: manually 
propagating (or using git submodule) any updates in the C source to the other (wrapper) packages 
for R, python, and Julia…], which allows the wrappers, like pycatch22, Rcatch22, and Catch22.jl, to 
work as standalone packages.

https://github.com/DynamicsAndNeuralSystems/catch22/issues/29

So upstream has no intention of going down the shared object route. We'll need to do it ourselves.

What do you think @music ?

What do you think? You’ll have to live with whatever we do, so I am happy to defer to your preference. I think any of the following are reasonable:

• Build a shared object ourselves as in this PR, and take care of bumping the .so version as needed (probably every time). Carry an unbundling patch in the Python bindings (probably a trivial one).
• As above, but keep the shared library out of the default linking path. I think I like this less and less the more I consider it, though.
• Just go ahead with bundling, since upstream doesn’t support an external library for the Python bindings and we’ve satisfied the requirements in https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling.

Sorry for the delay @music, fell down my task list..

Should we go with option 1 here for now, and we can always return to bundling in the future if required?

We haven't packaged/planned to package the R and Julia versions yet, so we can think about this again later if/when we get to those.

Housekeeping

Looking at the current version of the package, I assume this is still ongoing. Any updates?

Looking at the current version of the package, I assume this is still ongoing. Any updates?

I don’t want to speak for Ankur, but from my perspective it’s ongoing in the sense that the status quo was unsatisfying and we kind of quietly walked away from it in favor of working on other things.

I think I could be OK with reviving the downstream shared library patch approach. Upstream is not very active, and carrying the patch should be low-maintenance even though it is fairly intrusive. (But it mostly just moves complexity out of the existing spec file’s %build section since there is no upstream build system.) I do think I would want to try packaging the Python package and linking it against the proposed shared library before merging this PR.

Rebased without further work.

I spent a little time trying to build a python-pycatch22 package linked against the shared library from this PR.

The first thing I found is that the *_*.h pattern in https://src.fedoraproject.org/rpms/catch22/pull-request/3#_1__64 is bogus. All of the headers are needed.

Once I fix that, I find I can build a python-pycatch22 package against the resulting shared library with only trivial downstream patching in that package.

I guess that’s probably worth it.

I asked upstream to clarify if this is GPL-3.0-only or GPL-3.0-or-later.

The old Python bindings, python3dist(catch22), are still buildable from this repository, but once we have a python-pycatch22 package for python3dist(pycatch22) we should probably stop building Python bindings in this package and Obsolete them, since I think they’re just “repo cruft” rather than a maintained interface at this point. Note that https://pypi.org/project/catch22/ has only one release, and it’s been yanked.

Rebased on top of https://src.fedoraproject.org/rpms/catch22/pull-request/4.

Rebased on top of https://src.fedoraproject.org/rpms/catch22/pull-request/4.

I’m going to go ahead and merge both of these and prepare the review request for python-pycatch22. Once that package is in Rawhide, I’ll start backporting these PR’s and building the new package for older releases.

If we decide it was a mistake down the road, it’s not too hard to back out the shared-library approach and go back to bundling.