#417 sha2 library bundling in clementine
Closed: Invalid None Opened 10 years ago by nonamedotc.

I recently took ownership of clementine media player package in Fedora. Clementine media player bundles among other things sha2 library. The pacakge in Fedora has so far removed this and other "bundles" and been using sha2-devel for packaging.

But, the most recent version of clementine has had some API changes and it does not build against system library anymore. The bug report I filed is here - https://github.com/clementine-player/Clementine/issues/4217

I contacted the project leader (David Sansome) asking if the changes are specific to clementine and if the was planning to send those changes upstream. I am yet to receive a reply (I sent him the email on March 14).

It is my impression that the FPC does not in general grant bundling exception to crypt libraries. I have attached the differences between the two header files - sha2.h from fedora package and sha2.h in clementine.

Given this situation, I am unsure how to proceed with this package. Please advise. I would, of course, like to maintain the package in Fedora if at all possible.

Thanks!


Ugh. I hate it when upstreams do this. If upstream answered some of your questions we might grant a bundling exception. If upstream doesn't respond, we probably wouldn't.

As you already asked them, there's a question of why the changes can't just be merged with the upstream for the library.

There's also a question of why, if they are making changes that aren't suitable in the upstream library, they aren't producing their own library to do what they want (since in many cases the changes they make could be used by other projects as well). If they release their own library outside of clementine then it becomes clear that it's now a fork and it becomes easy for us to let you use it.

In this case where upstream is modifying the api but there's no clear reason why and the upstream, in fact, appears to still be segregating the code in their source tree, it isn't at all clear to us whether we should grant an exception or not. The only thing I can tell you at this point is that it appears you'll need to get more information from upstream if you want to continue to package this.

Thanks for the reply Toshio. I am going to contact upstream again. I will post any replies I get here.

I heard back from David.

My question:
Are the changes specific to clementine or would it make sense to split the library and release it as a fork (of sha2) it so that others can use it as well?

David's response:

I'm not sure what would make sense here. It's dangerous for any project to link to both sha2 and openssl - there are symbols in both libraries with the same name, and the runtime linker seems to pick one arbitrarily. I'm not sure why this has only bitten us on Debian so far (and specifically not Ubuntu) - maybe something to do with the way it's linked or exported the symbols in openssl.

It would make sense to rewrite sha2 as a wrapper around the corresponding functions in openssl, but I think the reason projects use sha2 to begin with is so they don't have to depend on openssl at all. The other alternative would be to namespace the symbols in sha2.h (like I did in Clementine) - maybe with a libsha2_... prefix. But that would break source compatibility with any application that used them.

My question:
If the changes are not specific to clementine, are you planning to send your changes to upstream?

David's response:
No plans from me - feel free to if you want to though.

Okay, so it sounds like clementine is simply namespacing the libsha2 functions. We probably want to propose namespacing to the libsha2 upstream and try to get similar changes applied there. That would allow unbundling of the hash library.

Thanks Toshio. I will get in touch with Fedora package maintainer and see what he thinks.

I have orphaned clementine since I have decided to concentrate my efforts on other packages.

Thanks a lot for discussing this in the meeting. I will close the ticket as "invalid".

Login to comment on this ticket.

Metadata