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.

+1 from me

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.