#8079: Better documentation for patching spkg's
-----------------------------+----------------------------------------------
Reporter: vbraun | Owner: mvngu
Type: enhancement | Status: new
Priority: major | Milestone: sage-4.3.3
Component: documentation | Keywords:
Author: | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
-----------------------------+----------------------------------------------
Description changed by mvngu:
Old description:
> It would be great if the best-practices for patching sage packages were
> better (at all) documented. The following blog post should be definitely
> included into the developer manual:
>
> http://mvngu.wordpress.com/2010/01/20/how-to-patch-a-sage-package/
>
> See also [http://groups.google.com/group/sage-
> devel/browse_thread/thread/e599fd37de909264 this discussion] on sage-
> devel for an example on how not to patch an spkg. The blog post
> [http://wdjoyner.wordpress.com/2009/08/01/evil-spkgs/ Evil spkgs?] lists
> some actions that an spkg must never do.
>
> In addition, I'd like to know how to deal with updated configure scripts.
> Some issues are:
> * The automake sources (configure.ac, Makefile.am, more?) are small and
> their changes need to be recorded in case upstream makes a new release.
> * The automake sources might be automake-version dependent.
> * Not everyone has all versions of automake installed, so spkg-install
> can't call automake.
> * Running autoconf/automake generates big shell scripts (configure,
> makefile). Differences in these need not be recorded.
> * But different versions of automake will produce different scripts,
> which would clutter up naive patches.
New description:
It would be great if the best-practices for patching sage packages were
better (at all) documented. The following blog post should be definitely
included into the developer manual:
http://mvngu.wordpress.com/2010/01/20/how-to-patch-a-sage-package/
See also [http://groups.google.com/group/sage-
devel/browse_thread/thread/e599fd37de909264 this discussion] on sage-devel
for an example on how not to patch an spkg. The blog post
[http://wdjoyner.wordpress.com/2009/08/01/evil-spkgs/ Evil spkgs?] lists
some actions that an spkg must never do.
In addition, I'd like to know how to deal with updated configure scripts.
Some issues are:
* The automake sources (configure.ac, Makefile.am, more?) are small and
their changes need to be recorded in case upstream makes a new release.
* The automake sources might be automake-version dependent.
* Not everyone has all versions of automake installed, so spkg-install
can't call automake.
* Running autoconf/automake generates big shell scripts (configure,
makefile). Differences in these need not be recorded.
* But different versions of automake will produce different scripts,
which would clutter up naive patches.
'''Related tickets:''' #8104, #3882
--
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/8079#comment:5>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
