On Wed, Jan 18, 2012 at 04:59, Julien Puydt <julien.pu...@laposte.net> wrote: > 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
Isn't this basically what sage-on-gentoo is doing right now? In fact, they take it even further - patches and setup scripts for ALL packages are in the same repository, and upstream sources for ALL packages are downloaded at build time. See http://github.com/cschwan/sage-on-gentoo . Burcin's lmonade ( http://lmona.de/ ) is doing something similar, but with Gentoo Prefix instead of Gentoo (so that you can run it on other distros). And it looks like the focus of lmonade is broader than Sage, by the way (just guessing from what I see on the website). Personally I think this kind of approach (sage-on-gentoo / gentoo prefix) is ideal for distributing Sage. We shouldn't need SPKGs at all. All the setup scripts being under one repository is a much better idea, as you said. -Keshav ---- Join us in #sagemath on irc.freenode.net ! -- 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
