On Wed, 18 Jan 2012 10:04:23 Keshav Kini wrote: > 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. > Let's not get out of focus here. Switching to stuff like sage-on-gentoo (on a prefix) or lmonade is in the future. We need to get it running properly first. The present is the fate of the twisted spkg.
A discussion on alternative building strategy for sage is nice but should really belong to another thread. For now, you are welcome to try it and tell us what's wrong with it in your opinion. There is definitely scope to talk about on sage-devel but in its own thread. Francois -- 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
