#399 request for bundled library exception - clustal omega
Closed: Fixed None Opened 5 years ago by nonamedotc.

I had submitted a review request for the package clustal omega. This is a very powerful command line tool for carrying out multiple sequence alignment. This software uses a modified version of a library called squid (http://selab.janelia.org/software.html) for handling inputs.

My package violates the No Bundled libraries policy in Fedora packaging guidelines and I am requesting a bundled library exception.

My reasons for requesting an exception are below -

Quoting from squid's author's website (link above) -

"A C library that much of the above software bundles in.
C function library for sequence analysis.

SQUID is my own personal library of C functions and utility programs for sequence analysis. I don't really suggest that you use it in your programs, as I change it at will. However, it does contains some small utility programs that some people have found useful in scripts that drive large HMMER tasks."

They do not have official releases to this library.

I contacted the clustal omega upstream to see if it was possible to submit their changes to upstream. They informed me that their changes are clustal omega specific.

I have attached the differences between squid upstream and squid library used by clustal omega here. Clustal Omega only uses a subset of squid's functionality and I am unaware of any program using squid as is.

So, it would be great if FPC can grant my request for bundled library exception.

This is a very useful software to have in fedora as a bioinformatics tool (even if the precompiled binary may be downloaded and used from the upstream website).

Thank you!


list of files different between squid upstream (squid-1.9g) and squid used by clustal.
files

changes in source code between squid upstream (squid-1.9g) and squid used by clustal omega
diff_files

  • Has the library behaviour been modified? If so, how has it been modified? If the library has been modified in ways that change the API or behaviour then there may be a case for copying.

Yes. Only a subset of squid (which is bundled) is being used in clustal omega. I have created a list of changes in detail and have attached it to this ticket.


  • Why haven't the changes been pushed to the upstream library? If no attempt has been made to push the changes upstream, we shouldn't be supporting people forking out of laziness.

As far as I can tell, two reasons - One, upstream (squid) does not care. They are providing the library as is. Two, the changes made to sqiud are specific to clustal omega.


  • Have the changes been proposed to the Fedora package maintainer for the library? In some cases it may make sense for our package to take the changes despite upstream not taking them (for instance, if upstream for the library is dead).

The squid library is not available in Fedora.


  • Could we make the forked version the canonical version within Fedora? For instance, if upstream for the library is dead, is the package we're working on that bundles willing to make their fork a library that others can link against?

From my interactions with upstream, they do not think it is a good idea to "unbundle" the package.


  • Are the changes useful to consumers other than the bundling application? If so why aren't we proposing that the library be released as a fork of the upstream library?

The bundling application (clustal omega) uses the library (squid) for obtaining input for sequence alignment. So, squid is an integral part of clustal omega.


  • Is upstream keeping the base library updated or are they continuously one or more versions behind the latest upstream release?

Upstream does not have regular releases. They change the library as they see fit (see the description from the upstream website posted in the ticket description).


  • What is the attitude of upstream towards bundling? (Are they eager to remove the bundled version? are they engaged with the upstream for the library? Do they have a history of bundling? Are they argumentative?)

They do not want to unbundle the library.


  • Overview of the security ramifications of bundling

Considering this library is used for a single purpose (taking input), I believe the security ramifications are minimal. But, my expertise in this area is minimal.


  • Does the maintainer of the Fedora package of the library being bundled have any comments about this?

This library is not available in Fedora.


  • Is there a plan for unbundling the library at a later time? Include things like what features would need to be added to the upstream library, a timeline for when those features would be merged, how we're helping to meet those goals, etc.

From my interaction with upstream, they do not have any plans to unbundle the library at present.


At today's meeting, this was discussed but we didn't have enough votes to pass it. Continuing voting in the ticket.

Proposal: "clustal omega has a forked copy of squid[http://selab.janelia.org/software.html]. Since squid was last updated in 2002, is a copylib, and clustal omega is the only user in Fedora, there is currently no benefit to a separate library. Permission to bundle has been granted unless some of those criteria change."

  • +1: geppetto, tibbs, abadger1999
  • -1:
  • 0:
  • Need votes from: spot, Rathann, RemiFedora, limburgher, racor, SmootherFr0gZ
  • Need two more +1's to pass.

At the meeting the following points were brought up:
This does leave us with the unfortunate case where another application might later be added to Fedora which also uses squid and we would then have to revisit this.
however, there is precedent: If you look at TexStudio's qcodeedit in approved bundling: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_granted_exceptions you'll see we used a similar set of reasons for allowing it.

This is currently at +4, though I don't know if the request is still relevant.

I'm -1. Most of the code changes look perfectly upstreamable, though a few are questionable. For example, the addition of min() and isnumber() macros if the respective functions are not defined should be done in a more portable way (and detection should be done in configure.ac). Another example is API modification. This should be done in a backwards-compatible way by factorizing common code and adding new function calls with different parameter sets while keeping the old ones intact. Clustal Omega should use the new APIs while other consumers can keep using the old ones.

For me, this is an example of sloppy coding because they couldn't be bothered to do it properly.

Given that there's been no response in the seven weeks since I pinged on this, I'm going to go ahead and close it. Feel free to reopen if there's additional information to provide.

Replying to [comment:9 tibbs]:

Given that there's been no response in the seven weeks since I pinged on this, I'm going to go ahead and close it. Feel free to reopen if there's additional information to provide.

Sorry, I have completely missed this ticket in my emails.

To answer rathann, squid upstream is not accepting patches. They said so ...

More importantly,

I misunderstood the vote many months back and the package is now approved. Should I retire the package and request re-review after this ticket is resolved? Please advise.

Thanks!

Here is today's meeting minutes, can you have a look through and answer any questions:

http://meetbot.fedoraproject.org/fedora-meeting-1/2015-01-29/fpc.2015-01-29-17.01.txt

Either way, we'll look at it again next week. Hopefully we'll get +5 and nothing needs to be done.

Updates after reading the meeting logs - both Jan 29, 2015 and the first meeting on Mar 06, 2014 (http://meetbot.fedoraproject.org/fedora-meeting-1/2014-03-06/fpc.2014-03-06-17.02.html)

  • regarding the quality of the code
  • My experience in this very minimal so I would (in all likelihood) be wrong in commenting on how good or bad the code is. So, I should pass. :)

  • Upstreamable code

  • This question came up in the first meeting as well. clustal author informed me that they did not try to upstream the code. But, I contacted the upstream author - my understanding is that they are not interested in getting any "outside" code changes.

If the FPC desires, I can clarify my interpretation with the squid upstream.

Thanks! Also, apologies for the earlier lack of replies.

FPC didn't have a chance to discuss this at today's meeting. This remains on the agenda for next week.

And just to make sure it's obvious (because after all this time it wasn't to me), the squid mentioned here isn't the Squid proxy server, but a "library of functions for biological sequence analysis".

I'm still +1 here. There's an interesting procedural question of whether the votes from Remi and Toshio still count now that they're no longer on the committee, but hopefully it won't matter.

We talked about this at today's meeting (​​http://meetbot.fedoraproject.org/fedora-meeting-2/2015-02-12/fpc.2015-02-12-17.05.txt):

  • 399 request for bundled library exception - clustal omega


    (geppetto, 17:47:11)
  • LINK: https://fedorahosted.org/fpc/ticket/399 (geppetto, 17:47:16)
  • ACTION: request for bundled library exception - clustal omega (+1:5,
    0:1, -1:0) (geppetto, 18:02:06)

Thanks for discussing and accepting this folks.

Metadata Update from @rathann:
- Issue assigned to james

2 years ago

Login to comment on this ticket.

Metadata