2013/4/23 Felix Salfelder <fe...@salfelder.org>: > Hi There Hi,
Sorry for only commenting in this thread this late; I have been very busy with my work and should still be for a few months, but always find some time to contribute and work on some personal projects :-) I had a sagemath review request for Fedora for several months, and only made the official review request after roughly 8 months working on it, in which time I got most dependencies updated in the base Fedora distribution: https://bugzilla.redhat.com/show_bug.cgi?id=877651 A few days ago I finally got the sagemath package approved, and after submitting it as update for f18, f19 and rawhide *yesterday*, it should now be reaching mirrors, afaik already available for rawhide in most mirrors, and should be shortly in updates-testing for f18 and f19: https://admin.fedoraproject.org/updates/sagemath-5.8-6.fc18 https://admin.fedoraproject.org/updates/sagemath-5.8-6.fc19 In the past I had kept a working sagemath package for Mandriva since late sagemath 3.x, and still have it somewhat working for "openmandriva" (I should update it to match the fedora package soon): https://abf.rosalinux.ru/openmandriva/sagemath > i have updated my proposal, taking into account the discussion. I've > mostly extended the Details section. Thanks for reading. I will make a few comments, attempting to be as constructive as possible :-) > === Title, Project Synopsis > "Get Sage ready for Linux distributions" > > Sage is currently shipped as a software distribution that, next to > genuine code, includes all dependencies as foreign packages. > Moreover, the core library and python modules cannot be compiled in a > straightforward way, as most linux distributions expect. Aim of this > project is to detach the build process of sage ("the software") from > sage ("the distribution"). The goal is a build system that works within > the context of sage as well as for any gnu/linux distribution that ships > the dependencies for sage. The biggest problem is compatibility of version of the components. Sagemath works in its current setup due to bundling most components, so that it can be built on a 3 year old distribution as well as on a bleeding edge one. Using a more standard build system should help, but, very close to what sagemath already does is kind of standard for several python based packages. Some more strict rules on spkg would make it actually easier to get sagemath integrated in distributions, example: o avoid carrying patches that upstream does not accept, or were never submitted upstream. o avoid creating spkgs of software that does not have a home page, or that is a snapshot of something without any ETA to be released, and not available anywhere for download. > === Personal involvement/relationship > To me, a Debian user, who likes maths (and doesn't like big Ms), this > project fills an obvious gap. I have already worked on packaging sage > dependencies for debian occasionally. There, I have learned some of the > basics of packaging and software distribution. I found out that a > package for sage cannot be done overnight... > > === Details > Switching the build system of the core parts to autotools allows > implementing a standard interface to build and install the software. > Such a build system includes a mechanism to figure out the > availibility/names/locations of tools/headers/libraries and adapts the > build/install process accordingly. One example is scons usage, that I patch to generate a more standard library: http://pkgs.fedoraproject.org/cgit/sagemath.git/tree/sagemath-scons.patch and after that patch, some regex are applied to SConstruct during build (to not hardcode cflags, ldflags, arch specific directories, etc). > An autotools build system can be used easily by package generation > scripts such as debhelper (creating Debian packages) and can be called > from within sage ("the distribution"). The difference between these uses > consists in passing different flags to the corresponding "configure" > script. > > This sums up to three tasks > 1 write/exchange the build systems for the core parts (c_lib, > python-sage, sage-scripts, extcode, ...). c_lib should be split out of the sage-$version directory. This way, IMO, there is not much of a need to change how the core python modules are built. Well, I would be happy enough to not need to add this pseudo patch: +if os.environ.has_key('DESTDIR'): + DESTDIR = os.environ['DESTDIR'] +else: + DESTDIR = '' [...] - pyx_inst_file = '%s/%s'%(SITE_PACKAGES, f) + pyx_inst_file = '%s%s/%s'%(DESTDIR, SITE_PACKAGES, f) to setup.py. > 2 modify sage ("the distribution") to use the new build systems instead > of running 'setup.py'. > 3 build stand-alone sage, draft debian packages, figure out dependencies > > which split up into [optional in brackets] > 1 - carefully read setup.py (within the sage-git-transition repo) > - implement checks for headers and libraries > - implement configure switches where needed I see this as a great improvement, but also consider adding checks in the more pythonic way to the "current" build system. > - find convenient/flexible way of writing down targets (Makefile.am > layout etc.) > - templatize {module_list,setup}.py or convert to Makefile.ams. > - figure out run-time-paths, patch where needed. > - sort out sage-scripts, make paths configurable > - handle the other directories in src > 2 - compile sage ("the distribution") > - carefully read top-level Makefile > - somehow handle sage-scripts ("bin") and doc > - figure out configure environment/switches needed within sage > - (add additional options if/where needed) > - adapt toplevel Makefile module installation > - run test suite... > - [draft "toplevel configure"] > 3 - install dependencies on a debian machine > - compile everything > - prepare sage-scripts for system wide installation My current approach is to add the location of sage scripts to $PATH, and besides some symbolic links from system directories to SAGE_ROOT, in most sage scripts I just remove in a patch the hardcoded $SAGE_LOCAL/bin prefix to binaries. > - create source package out of <git-transition-repo>/src > - write control file/rules etc. > - run tests on debian [gentoo] > - [package sage-notebook] > > Interfaces > Currently there is one static Makefile in the toplevel directory that triggers > the build process of all packages and installs them into a local directory. > The new build system will expose the following interfaces > - Configurable build systems for all modules > - A configurable build for sage ("the distribution") > > The build systems for the core (non-foreign) modules are meant to be used by > distributions (like debian) in a straightforward way. This is done by > picking out the embedded modules for packaging. For debian that means, > the <gitrpo>/src directory will make (exactly) one source package, from > which all the modules are built. > > Sage ("the distribution") will permit builds in different flavours, > controlled by the configure script > - same as before (default) > - install core+notebook (sage "the program") > - skip a subset of the modules (optional within this project) > - skip modules that are already installed elsewhere (beyond the scope of this > project, needs changes in external module handling) > > Rationale > This proposal targets distribution-friendliness by exploiting the modular > structure. Once every module can be built in a straightforrward way, any > (linux) distribution can package it. > Making sage ("the distribution") use these build systems internally is a key > feature. This is the proposed way to make sure that packages created today > will > work with sage releases tomorrow. > > Discussion > There is some controversy on the sage-devel mailing list [2]. I'll list > the key objection and explain how I'm trying to deal with them. > > - (embedded) modules is too much work. > It's true that modularization has its price. Before the git-transition Sage > was > using modules (spkgs) for its parts (even without distribution friendliness). > This project will in fact revert some of the modularization loss, and will > demonstrate that using modules is even less work in the long run. > > - when installing (one/all) sage core module(s), the notebook module > should be installed as well (if\ desired/sometimes/always). this is > "sage the program". > injecting distribution functionality and package handling into the > module build systems undermines the logic of any distribution. this > is too complicated. installing "sage the program" is intended to be > possible by installing sage ("the distribution") skipping foreign > modules but picking the notebook. this approach will continue to work > even after someone declares another foreign package to be part of sage > ("the program"). > > - too many modules with extra build systems > indeed. this approach will handle any of the subdirectories in > <git-transition-repo>/src as submodules, which may be seen as overkill. > but it has also some advantages. the build systems for the modules are > shorter, > the checks can be associated to the parts of code they belong to, the build > system type may be chosen individually, and most importantly the directory > structure remains unchanged. remind, that currently the "build system" in > <gitrepo>/src consists of an opaque patchwork of build systems. this project > will clean up and move the intermodular glue to sage ("the distribution"). > after all, merging build systems (of the same kind) is a trivial task > and can be done once everything is working (or at any time the upstream > directories change). > > === Schedule > During the GSoC period I have no university work obligations as I'm on > parental leave. > > - I won't be at home May 3 till May 19. still trying to stay connected > - From July 27 to Aug 4 I will be most likely unavailable > - i'll be away another two weeks in summer (Jul/Aug), not fixed yet. > > === Risk Management > The tasks list includes the inevitable parts and doesn't promise an > instant switch to a different build system. This would be the ultimate > goal for the sage project, beyond the scope of a GSoC project. > > As far as the directory tree permits, new build systems can coexist with the > current one. thus, integration is not enforced, and the switch can be > performed > after everyone is satisfied. > > There is hardly any risk, that work done within this project turns out > to be useless. If difficulties occur, the modularity of the approach > allows postponing problems in 1 while still continuing to work on 2 and > 3. On the other hand, if time permits, I can work out the optional > parts. While it is not trivial, it has been done before to Debian as you already know, http://wiki.sagemath.org/devel/DebianSage So, one of the major issues should be continued maintenance. It is very important to have "core" sagemath developers as distro packagers; personally, I would be very happy in mentoring and giving comantainership of sagemath for Fedora, and for Debian it should not be much different. > regards > felix > > [1] > https://docs.google.com/document/d/1ipzvwbhfujaubDe0QVO-V9JmmRcLZvitaeXh4r2WNqA/pub#h.pty9ayy9wo8 > [2] https://groups.google.com/forum/?fromgroups#!topic/sage-devel/1HGbf4EZGb0 Paulo -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
