Hi there. On Thu, Apr 11, 2013 at 11:41:17AM +1200, François Bissey wrote: > From the point of view of a linux distribution, my opinion is that the > package > management system should be extracted. If it comes from your distro the > packages and upgrades are handled by the distro mechanism, except for stuff > that (can) live in the final user home directory.
i do not really understand this. are you saying that the linux distribution should take over the role of the sage package mechanism? if so, would that mean that sage components should work independently of the sage packaging method? > Sage itself has currently several components that are shipped separately and > at least one that should be split: > sage_root: which has all the elements of the basic build system and > traditionally the scripts to start sage. > sage_scripts: a collection of various scripts and command to run and tests > sage. > extcode: various bits and pieces accumulated over time. I understand it will > disappear in the git migration being integrated elsewhere. > sage: the python extension itself plus the c library. The c library is the > element we think should be split (and we do in sage-on-gentoo). are you implying that its a good idea to split components and ship them as seperate packages? the sage-to-git transition apparently does the reverse. how does this affect the gentoo-packaging? > Whether to keep this structure in Debian or after the git transition is not > for me to answer. But I strongly believe the c library needs to be available > separately from the python library. in debian, one source package can create multiple binary packages. this for example makes sense, when seperate (but related) lib*, *-dev, *-doc, *-dbg packages are convenient. packing unrelated stuff from a single source repo do different binary packages usually leads to overhead within the rules (which will probably not even work for the next release). so theres the inevitable question to ask: would it be an option to eventually split c_lib and the python modules to different packages? > The c library is built with scons which > has its detractors (that includes me) but is seriously too small to justify > autotooling in my opinion. all i (need to?) know about scons is, that there is no visible concept of configure. particularly there is no way to pass --with-this-and-that=/my/favourite/path switches in a practical way. so if the c_lib is small, that would make transition to something else even fast. > > It would still be nice if the top level script could be used by > > distributions. There are still several things to build and other things > > to do, if external dependencies are not built, and we should not > > implement all this in debian/rules. One could start with the option to > > build all or none of the dependencies and then maybe go further to allow > > more combinations. But I'm also not entirely sure if combining system > > and bundled dependencies is needed. Maybe an alternative build script > > for building with system libraries would be a better idea. Are there > > other opinions? > > > > The questions has arisen several time in the past 5 years but in spite of some > suggestions on how to achieve this, no one has done the work. You are welcome > to have a go at it. If you start it you may get a surprising number of > helpers. I think most of the inertia is in starting it. i'm not convinced. once all parts (including python-sage and c_lib) are in a distributable/configurable shape, any distribution will be able to pick them up easily. especially there will be no need for distributions to use sage's built in top-level script. whatever a top level script does, it will never fit the needs of all distributions at once. just think about building a multiarch ready package out of c_lib, while it is only accessible within a tarball containing the sources of five other packages, through a patchwork of a sage-toplevel script and an spkg-install script calling "scons install" through a static makefile (or setup.py or whatever). have fun felix -- 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.
