changing upstream for an experimental package

[Dima Pasechnik]

For http://trac.sagemath.org/sage_trac/ticket/14505, I needed to
libtoolize a rather old source (unchnaged for last 6 years), to get
rid of a bunch of messy Makefiles etc.
Apart from that, the change was in the layout of include/.
I imported the upstream svn repo into git, and put it up on github.
While it's perfectly possible to make a cumulative diff against the
upstream source, and use it to create the spkg, I rather prefer
to use the modified source on the git repo.

Another concern is the history of spkg-specific files;
following libGAP's example I only provide a fake hg repo in the spkg,
with the real history of changes documented on github.

Any thoughts about this?

Thanks,
Dima

[Volker Braun]

Libgap also modifies each source file (global symbols are prefixed with libGAP_...), so its not exactly a comparable situation. I'd say if you just change autotools  / Makefiles then its easier to make it a patch. If you make heavy changes to the sources (is that legal in this case?) then it'll eventually become easier to make your own fork.

[Dima Pasechnik]

On 2013-04-30, Volker Braun <vbrau...@gmail.com> wrote:
> ------=_Part_4004_20928279.1367304370235
> Content-Type: text/plain; charset=ISO-8859-1

>
> Libgap also modifies each source file (global symbols are prefixed with
> libGAP_...), so its not exactly a comparable situation.

So if you modify files you can have it nice and easy, and
otherwise one has to bite the dust making patches by hand?
I beg to differ, I think that the ease of maintainance must take the
precedence over a rigidly understood "unmodified source" principle, or
whatever is left of it in this case.

E.g. I remember debugging a version of maxima spkg a while ago, it was even
not possible to find out exactly which point of maxima source tree
the damn thing was made from...

> I'd say if you just
> change autotools / Makefiles then its easier to make it a patch.

I find messing around with patches this way burdensome and error-prone.
In particular this would mean maintaining two repos, one mirroring the
changes in a part of the other one, instead of one.
Instead, libGAP takes the route of saying: "it's not a real repo in the spkg,
go to the real one if you want the history".
So this must be OK in other spkgs, no?

> If you
> make heavy changes to the sources (is that legal in this case?)

I don't see what can go wrong with modifying code under this licence and
distributing it non-commercially.
https://github.com/dimpase/csdp/blob/master/LICENSE

> then it'll eventually become easier to make your own fork.

well, it is all already done and waiting for a reviewer!
Now potential reviewers are telling me to ask on sage-devel
whether it's kosher to make spkgs this way...

Dima

[Volker Braun]

You shouldn't make patches by hand, its easy to make diffs between any two revisions once you have checked in everything. At least you have an upstream source tarball, GAP thinks of itself also as a distribution of mathematical software... 

Is its still under the "Common Public License"? IBM at one point agreed to supersede it with the EPL. 

In the end, the question is whether you just want to build a spkg or if you want to fork upstream. Both approaces have advantages and disadvantages.

Volker

[Dima Pasechnik]

On Tuesday, 30 April 2013 22:35:18 UTC+8, Volker Braun wrote:

> You shouldn't make patches by hand, its easy to make diffs between any two

> revisions once you have checked in everything.

sure, I can do this. But I don't want to mess around with carrying over the spkg's metafiles/scripts hg

history in a special repo.

And if I can fake the history the way libGAP does, why can't I do the

rest the way libGAP does it?

> At least you have an

> upstream source tarball, GAP thinks of itself also as a distribution of

> mathematical software...

>

> Is its still under the "Common Public License"? IBM at one point agreed to

> supersede it with the EPL.

the license is imposed on the CSDP author by his employer. He told me he

doesn't think it's possible to change.

>

> In the end, the question is whether you just want to build a spkg or if you

> want to fork upstream. Both approaces have advantages and disadvantages.

I want CSDP to be easy to build, both in and out of Sage.

Actually, many files are touched, as I changed the layout of headers to

make it easy to pick up with autotools. (and so #includes get changed

too)

Call it  chopsticks... :)

Dima

[Volker Braun]

On Tuesday, April 30, 2013 4:01:44 PM UTC+1, Dima Pasechnik wrote:

the license is imposed on the CSDP author by his employer. He told me he

doesn't think it's possible to change.

IBM came up with the Common Public License and later deprecated it in favor of the EPL. Both are GPL-incompatible, but at least if the employer in question is IBM then the license should probably be updated (by upstream) to the EPL.

[Dima Pasechnik]

it's New Mexico Tech., not IBM...