[Debian-science-sagemath] Build-Depends on source itself [libgap-sage]

[Paul Wise]

On Wed, Nov 2, 2016 at 11:22 AM, Jerome BENOIT wrote:

> Let give a try. I am dealing with the libgap-sage package [1].

Thanks for the extensive details.

> To begin with, GAP is a Computer Algebra System (CAS).
> From an upstream point of view, libgap is not part of GAP itself.
> libgap is rather a library wrapper for gap meant to get a better
> access to the GAP kernel and to be used within Sage, which is a kind
> a umbrella for multiple CAS (GAP, Singular, and a myriad of scientific oriented software packages).
> Note that, for now at least, GAP itself does not furnish any library; hence libgap.

The libgap project seems like a workaround for this bug in GAP?

> Basically libgap adds a prefix to the GAP functions and variables,
> and gather them in a library. We must have in mind the following points:
> 1] The libgap source ball provides the modified source files with some delay
> (current modified gap version in libgap is 4.8.3 while the current gap version is 4.8.5 ,
> this version being the one in Stretch. In any case, the copyright headers of the source files
> are not modified, so they cannot be packaged for copyright reasons.

That seems like a very suboptimal way to do it.

> 2] The scripts that modify the original GAP source files is not distributed within
> the libgap upstream source ball, but it is available via the libgap git repository [2] at Bitbucket
> along some documentation for generating our own modified GAP source code. The current Debian source ball
> for libgap is the git repository material (which unmodified contains but obsolete GAP material, version 4.8.3).

Ok, I'm glad this is not a DFSG violation. It could easily have been one.

> 3] The libgap Debian package must be synchronized with the GAP Debian package, so modifying the (potentially)
> patched GAP src/ is certainly not only a good idea but also a factor of stability and good maintenance.

Agreed.

> 4] Just the material in the subfolder src/ within the GAP source ball is needed, that is to say, not the all
> source ball.

Makes sense.

> 5] We want a long term solution to ease the maintenance of Sage[Math] and its friends.

It seems clear to me that the only sane long-term solution is for GAP
upstream to add a proper shared library. Has this been discussed with
them at all? Until GAP upstream are willing to do this, I suggest one
of the following:

Drop the libgap-sage source package entirely and add a secondary
tarball to the Debian GAP source package containing only the libgap
scripts and have the Debian build process for GAP use those scripts to
create libgap-sage dev and lib binary packages. dpkg-source format v3
can have multiple tarballs, which makes this doable sanely.

OR

Get the GAP sources removed from the Bitbucket repository.

Have the build scripts in the libgap Bitbucket repository:

1. require info on which source tree to copy or which version to download
2. copy that source tree or download that version
3. modify the local copy using the scripts as per normal
4. build the scripts as per normal

There might need to be some checking of the copied source tree to make
sure the scripts still support it.

Create a gap-libgap-sage-source (or similar) package from the GAP
Debian package, containing the GAP src/ directory somewhere under
/usr/src.

Have the libgap-sage package build-depend on gap-libgap-sage-source
and point the libgap scripts at the GAP src/ directory under /usr/src.

Make sure that the libgap-sage package is binNMUed or rebuilt after
every gap upload. I expect the script will need to change reasonably
often due to changes in GAP though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise