Could you please provide us with answers to:

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Standard_questions

so that we can better evaluate this request? Thanks!

Replying to [ticket:326 sergiopr]:

The number and types of arguments of the function "mpfit" in bundled cmpfit have been modified, with the purpose of interfacing with Python via Cython. Even with the system cmpfit library installed, kapteyn would need its own modified version.

I hereby request an exception to bundle cmpfit in python-kapteyn

I reviewed the code changes and they're not extensive. There are two API changes. One is the removal of one parameter of mpfit() function and setting it to 0, which is not necessary and can be done in calling code (just call with that parameter equal 0) and the other changes two parameter types of mp_func type definition from int to int * and from double * to double * *, respectively. This would need some explanation from upstream, but I believe it can also be worked around in the calling code.

Please update this ticket, providing any information requested. If this is not done within the next week, this ticket may be closed due to inactivity. Thank you!

I'm currently out for vacation, I'll contact upstream when I'm back this next Friday

I have sent an email to upstream today.

Answer to common questions:

=== Has the library behaviour been modified? If so, how has it been modified? ===

The function mpfit has been modified to interface with python via cython.

There are both API and internal changes. In the API side, an integer argument
has been removed and two fileds of the structure mp_func have been changed
from int to int and from double to double. Internally, the initial
evaluation of the user function has been moved to a early point in mpfit,
as well as the temporary storage allocation. The purpose of this modification
is to eliminate the need to supply
the number of data points when mpfit() is called from Python, where
this number is available implicitly.

=== Why haven't the changes been pushed to the upstream library? ===

The changes are relevant only for the Cython interface.

=== Have the changes been proposed to the Fedora package maintainer for the library? ===

cmpfit is not in Fedora yet (note bz #1001194). The changes are relevant
for the Cython interface only.

=== Could we make the forked version the canonical version within Fedora? ===

No, it has a different functionallity.

=== Are the changes useful to consumers other than the bundling application? ===

Not really, unless the library is unbundled together with the Cython interface,
which does not make much sense.

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

The last version of cmpfit is 1.2 (2010) and that's the version bundled.

=== What is the attitude of upstream towards bundling? ===

When I contact them, they understood the reasons to unbundle libraries.
I'm quoting here from their answer:

Fedora, as other Linux distributions, puts effort to unbundle libraries
that are shipped inside other packages. There are good reasons to do that.

I understand these reasons. We decided to bundle software for mainly two
reasons. One is that in practice users often experience problems due to
the absence of an external package or due to incompatibilities between
versions. In a repository like Fedora's, these problems can be implicitly
eliminated and that's good. The other reason is that we sometimes need to
modify software to our needs.

(snip)

The function mpfit has been modified from what is distributed in cmpfit.
My question is if it is still possible to put the modifications in a
function, call it mpfit_kapteyn, that calls the unmodified mpfit function
from upstream cmpfit.

Unfortunately I don't think this is possible. The original function mpfit()
requires the number of datapoints to be specified beforehand while in Python
this only becomes available in a natural way when the residuals function is
called from mpfit().

=== Overview of the security ramifications of bundling ===

This library is used for fitting functions inside an astronomy package.
I do not foresee security problems.

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

The package is not yet in Fedora (but see bz #1001194).

=== Is there a plan for unbundling the library at a later time? ===

Not that I'm aware of.

Is there anything more I can do to get this reviewed?

Could you ask upstream to try and work with cmpfit upstream to add the missing functionality instead of forking? If kapteyn needs a different API then it' better to add it as a new function without modifying the existing functions instead. Given how small the changes are, I believe this should be easily doable.

I have retired from the review of the package originating the exception. This ticket can be closed.