On Wed, Apr 10, 2013 at 4:04 PM, Tobias Hansen <than...@debian.org> wrote:
> Am 10.04.2013 17:43, schrieb Felix Salfelder: > > several parts of fixing/changing/improving the sage (the system) build > > system is unrelated to distributing sage "the library". so "changes to > > the build system in Sage" is somewhat vague. > > > > i think a build system for the sage library should at least check > > availibility (especially optional dependencies). more checks for > > versions/header functionality/existing symbols are implemented within > > autotools. the universal way would be maintaining these checks (which > is unrealistic). catching common caveats should be possible. > > > > I mostly thought about the build system of the Sage system until now and > didn't think about the build process of the library. Since availability > of dependencies is ensured by the Sage system, the build process of the > Sage library doesn't check for dependencies, right? Your idea is to add > dependency checks to the library build, and that may be a good idea, but > one could also consider to let the top level build scripts keep the job > of handling the dependencies and do the checks there. I'm not saying > that this would be better, just that this was my idea until now. > > >> Every distribution has its own way to organize > >> patches. I think Sage already has a good test coverage and a Debian > >> package should of course run all the tests during build. > > > > iirc the tests are contained within sage.spkg (where the library is), so > > that should be possible. other tests may come within other spkgs. > > > > Remember the git transition. spkg's will go away. There will be just one > tarball containing everything in the future. The sources of other > projects will be better separated, so it will be easy to get a Sage > tarball without sources of other projects. Taking this into account, it > probably makes sense to have only one Sage "Debian source package". > spkgs won't fully go away -- with the initial transition we are simply emulating the current spkg model. That said, there has been some work in transitioning to the ebuild format to use portage as a package manager -- but from what I understand, this is still a ways off. One thing to note with the git transition is that I made an effort to (mostly) separate the build system from the sage library (by this I mean the core components of sage: the python library, csage, documentation, scripts, ...). So hopefully this will help in determining what is needed in packaging sage. For those so inclined to browse the current status of the git transition, the repository is at https://github.com/sagemath/sage. > >> It seems to me that you understood that Sage should build all spkg's > >> in any case and just install them somewhere else. I think that means > >> the step you call "fix Sage the operating system" is not needed > >> right? Now that I have clarified this, any new thoughts? > > > > for debian or other distributions, i dont see the need for any changes > > to sage (the system). making sagelib distributable doesn't help skipping > > spkgs. so there are still two subprojects: > > > > - improve sage (the library) distributability > > - enhance setup.py (better switch to autotools) > > - get libcsage.deb and python-sage.deb packages > > - run the unit tests from debian/rules > > - (also pack other stuff) > > - pave the way for local spkgs (e.g. installed to ~/.sage/local) > > - [..] > > Switching to autotools is something we can't decide alone. What do Sage > developers say? Do you mean with "Sage (the library)" all Sage > components including notebook etc? > > > - "fix sage the system" > > - implement/incorporate top level configure script > > - figure out flags, pass down to spkg-compilation > > - build sage the upstream way skipping some spkgs > > - [..] > > > > in fact, the second is not needed, neither for me, nor for the debian > > package. the project description implies something different, which is > > confusing. > > > > 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? > > Cheers, > Tobias > > -- > 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. > > > -- Andrew -- 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.
