#11246: flint-1.5.0.p5's extraneous #includes break typedef ulong in sys/types.h
---------------------------------------------------+------------------------
Reporter: dimpase | Owner: tbd
Type: defect | Status:
positive_review
Priority: major | Milestone:
sage-4.7.2
Component: packages | Keywords: cygwin
Work_issues: | Upstream: N/A
Reviewer: Karl-Dieter Crisman, Leif Leonhardy | Author: Dima
Pasechnik, Jeroen Demeyer
Merged: | Dependencies:
---------------------------------------------------+------------------------
Comment(by leif):
Replying to [comment:49 dimpase]:
> IMHO, this discussion just highlights a need to revamp the whole spkg
system, for 99% of the standard spkgs, at least.
> It would be much better if the whole non-building part of the spkg
install is done in a uniform way, by hg, say,
> rather than handwritten scripts...
>
> The need for the current spkg system is dictated by the need of some
optional parts of Sage, that demand, say, a distribution in an unmodified
form. Yet, putting the spkg source under hg is not a modification. Sage
can distribute spkg source with the hg tree, and Sage-needed patches as
patches to be applied by an spkg-install.
If I understand you correctly (having the whole upstream tree under
revision control), that would heavily increase their sizes.
I'd rather vote for splitting off the whole vanilla source trees (`src/`)
and ship them as separate tarballs (perhaps just repackaged with `tar` and
`bzip2`), along with cut-down Sage-source only `.spkg` files (preferably
with a new extension, say `.spi`).
`sage-spkg` then could take care of the upstream packages, putting their
appropriate, corresponding versions into place before calling `spkg-
install`, i.e. extracting them into `src/`, such that we would not even
have to change anything in the existing `spkg-install` and `spkg-check`
files, the Sage part of spkgs.
That way, we could even have a single spkg (or "spi") repository, which
would greatly ease working on spkgs and merging changes. Also, this would
not only decrease the download size upon upgrades (assuming just Sage's
patch level changed, which is often the case), but also the overall
traffic when reviewing spkgs, and -- last but not least -- the "new"
spkgs, which could then be ordinary Mercurial changesets to simply be
applied to the spkg or "spi" repository, could be attached to the tickets
and merged like any other changes to Sage, i.e. the library, scripts
etc.).
Instead of e.g. `foobar-x.y.z.pN.spkg`, we would have
`foobar-x.y.z.tar.bz2` (vanilla upstream), perhaps in
`$SAGE_ROOT/spkg/standard/upstream`, optionally but preferably a Mercurial
repository in `$SAGE_ROOT/spkg/standard` (ignoring `upstream/`), and the
stripped-down `foobar-x.y.z.pN.spi` files in `$SAGE_ROOT/spkg/standard`,
or even just `foobar-x.y.z.spi` if they are under ''central'' revision
control.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11246#comment:63>
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.
