Le 17/01/2012 21:10, Jason Grout a écrit :
On 1/17/12 2:04 PM, Julien Puydt wrote:
Le 17/01/2012 20:54, Jason Grout a écrit :
On 1/17/12 1:38 PM, Julien Puydt wrote:
Le 17/01/2012 15:33, Jason Grout a écrit :
If we separate out twisted on principle, it seems like we should
separate out the other 13 dependent packages that are included.
That's a
maintenance burden I can't take on right now.
Are those heavily patched with respect to upstream?
None, including twisted, are patched with respect to upstream.
Why is there a maintenance burden for pieces of code which upstream
takes full care of?
The maintenance burden is in making and releasing a new spkg for every
single upstream update if we split those off into separate spkgs,
compared to the sagenb spkg automatically downloading and including
necessary dependencies in itself.
This is something I have noticed : on the other hand, having spkg means
that to share some experimental code with inexperienced people, it's
just a single file to transmit, and it will mostly just work. This is
good, and must stay!
On the other hand, that means that each spkg is its own repository,
which is quite a pain during development. For example, sage may have
foo-3.14.p3, and on some bug report, someone comes up with foo-3.14.p4
with a patch (and must hence share the whole big archive instead of the
one-liner patch) ; and on another bug report, someone else has a
foo-3.14.p4 with another patch (same problem). This also implies that
when a new upstream comes, a new spkg must be made, which isn't that
trivial. A maintenance pain, as you put it.
Does it really make sense to have the shipped (both mandatory and
optional) parts of sage as spkg? Spkg is nice for optional *and*
external stuff, why would it make sense for the "base" install?
Wouldn't it be better to have sage structured like this somewhere (just
the inspiration of the moment, don't take this as a polished and perfect
design document) :
sage/
mandatory/
upstream/
foo-3.14.tar.bz2
bar-20120115.tar.bz2
...
foo/
patches/
build-script
bar/
patches/
build-script
...
optional/ (but shipped with sage)
upstream/
...
whatever/
...
...
spkg/
(the necessary things to list, download& install spkg)
where the tarballs in the upstream directories are the upstream
*unmodified* archives.
The advantages would be :
- everything is under the same revision control tree (no more one
repository by package [and worse, a tar+bzip2-ed repository!]) ;
- just share patches of a few bytes instead of several megs ;
- it's easy to see if sage has specific patches for something or not ;
- updating a package can be as simple as dropping the new upstream
tarball, remove the old and change the version number in the
corresponding build-script (one-liner).
- it's easier to share in-progress work within the community : just get
the repository, and you'll know what is 4.8.alpha1 [it's tagged], you'll
even see the changes of the day by the maintainers ;
Just some thoughts,
Snark on #sagemath
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URL: http://www.sagemath.org
