[sage-devel] Re: Packaging Sage?
As far as I'm aware, everyone's current solution to packaging sage is to more or less completely ignore its own build system and do everything manually in whatever specification format your package manager uses. You will need to make sure it keeps working once the dependencies change. The test suite is pretty brittle, but invaluable. It can be done, but you should be aware that its pretty labor intensive. Timo Am Sonntag, 10. Mai 2020 15:02:24 UTC+2 schrieb Thierry Thomas: > > Hello, > > TL;TR: Packagers, how do you deal with Sage to package it for your Linux > distribution (or *BSD system)? > > Details: > > Sage has been ported to FreeBSD many years ago (4.8), but now the port > is lagging and no more packages are built; I'm trying to fix it. > > Problem: on FreeBSD, packages are built (by a porter or in the > compilation farm) as a regular user, and installed in a staging > directory (DESTDIR); then the package is installed as root in the final > $PREFIX (ldconfig and so on are executed). > > The naming may differ, but many packaging systems have a similar > mechanism. > > But Sage cannot be built with this method: the global install target is > a no-op, and every sub-package is built and installed during the build > target, under $SAGE_LOCAL, and everything is built relatively to this > directory. If you try to move the resulting bits to another directory, > it becomes unusable. > > $SAGE_DESTDIR is handled, but does not solve this problem. > > A first way to deal with it is to use as many system packages as > possible (see #27330): Sage´s libraries built around a system package > are safe. > > For example, with the stock sage-9.1.rc3, when setting SAGE_LOCAL to my > staging directory, these errors are emitted for cvxopt: > > Error: 'lib/python3.7/site-packages/cvxopt/umfpack.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/base.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/amd.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/misc_solvers.so' is referring > to /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/blas.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/gsl.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/cholmod.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/glpk.so' is referring to > /usr/ports/math/sage/work/stage > Error: 'lib/python3.7/site-packages/cvxopt/lapack.so' is referring to > /usr/ports/math/sage/work/stage > Error: > 'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_sdp_backend.so' > is referring to /usr/ports/math/sage/work/stage > Error: > 'lib/python3.7/site-packages/sage/numerical/backends/cvxopt_backend.so' is > referring to /usr/ports/math/sage/work/stage > > When using cvxopt from a system package (see #29665), these errors are > resolved. Unfortunately, even if the proposed method seems OK from my > packager´s POV, it seems that this is not the way to go: see #29023. > > Several interesting propositions exist in #29133 (#21566), and things > like #29653 are also helping, but these are middle or long term goals. > > And so my initial question: how do you package the actual releases? (9.0 > or 9.1) > > Many thanks for reading and for your feedback! > -- > Th. Thomas. > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/44cee254-250c-4a69-ad34-7247f1535e50%40googlegroups.com.
[sage-devel] Re: Packaging SAGE for (re)distribution in RPM form
On Jan 15, 2008 11:50 PM, mabshoff <[EMAIL PROTECTED]> wrote: > > > > On Jan 16, 5:23 am, gri6507 <[EMAIL PROTECTED]> wrote: > > I've posted several thread on this topic now - mostly with question. > > But now, with the help of several members in this forum, I finally > > have my first release of an RPM > > (seehttp://www.mypclinuxos.com/forum/index.php?topic=1509.msg13310#msg13310) > > > > One more thing: To quote from the above thread > > "On a slightly different note, one [hask/kant] of the preferred > packages for SAGE seems to be only distributed as precompiled binaries > despite the fact that it is open source." > > kash/kant is closed source as you found out yourself, but I wouldn't > even go remotely as far as calling it "preferred". It is optional, but > I think we should go further and add a non-free section to the spkg > repo, just like Debian, to make it crystal clear that it is not open > source. I think this is a good idea too. > > Cheers, > > Michael > > > > > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Packaging SAGE for (re)distribution in RPM form
Thank you for the reply. I redistributed the .hg folders into the devel package. As for your warning, I completely understand the origin of the concern. I, along with the rest of the packaging community at PCLinuxOS, will have to wrestle with this one later. --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Packaging SAGE for (re)distribution in RPM form
On Jan 16, 5:23 am, gri6507 <[EMAIL PROTECTED]> wrote: > I've posted several thread on this topic now - mostly with question. > But now, with the help of several members in this forum, I finally > have my first release of an RPM > (seehttp://www.mypclinuxos.com/forum/index.php?topic=1509.msg13310#msg13310) > One more thing: To quote from the above thread "On a slightly different note, one [hask/kant] of the preferred packages for SAGE seems to be only distributed as precompiled binaries despite the fact that it is open source." kash/kant is closed source as you found out yourself, but I wouldn't even go remotely as far as calling it "preferred". It is optional, but I think we should go further and add a non-free section to the spkg repo, just like Debian, to make it crystal clear that it is not open source. Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Packaging SAGE for (re)distribution in RPM form
gri6507 wrote: Hi, > I've posted several thread on this topic now - mostly with question. > But now, with the help of several members in this forum, I finally > have my first release of an RPM (see > http://www.mypclinuxos.com/forum/index.php?topic=1509.msg13310#msg13310) > > I now want to do two things. The first is to trim down the size of the > RPM by stripping out content that is simply not necessary. To do that > I'd like to ask here if you believe the following directories are > needed in the "make install" process: > > /usr/lib/sage/data/extcode/.hg/ > /usr/lib/sage/local/bin/.hg/ > /usr/lib/sage/spkg/base/.hg Those repos are used in the development process. From our end it is always assumed that each Sage install, even the binary ones can do development out of the box without the need to install anything. Removing those repos makes that harder/impossible. Maybe that assumption does not hold any longer for a certain target audience, but I would suggest that you package those components in a sage-dev.rpm for people who want to do development work. Otherwise they will end up hearing "just install from vanilla source" from us anyway. > /usr/lib/sage/spkg/build > /usr/lib/sage/spkg/optional (possibly don't deliver what was already > installed?) > /usr/lib/sage/spkg/standard (possibly don't deliver what was already > installed?) Those should be empty or the content of the spkg replaced by dummy files. If you do not have those in the installed version any attempt to upgrade will fail or you will end up redownloading and rebuilding all components. Since those dummy files are all very small I don't think removing those will have an impact on the rpm size. > The second thing is still in the works. Since a number of libraries > built by SAGE already exist on the system, I'm working on modifying > the SAGE build process to pick up those instances instead. I still > have a while to go, but it's well on its way. I'll post my progress on > this part later. Well, the idea with the Debian effort is to update the distribution's packages to the version we ship or alternatively update our packages if the ones on our end aren't uptodate. 2.10 will make a large step toward updating spkgs on out end. I would also think that a monolithic rpm of Sage is of little use versus the tarball. If you end up replacing components please make it clear via some version string that you are shipping a modified version of Sage since otherwise we might end up chasing bugs in the components that your distribution ships. The tight integration of Sage was done for specifically this reason, i.e. just assuming that components on people's systems do work ended up being a support nightmare. It will also be hard for to keep up with the spkg changes on our end if you go into individual spkgs and adjust certain targets there. One option would be to "skip" over certain spkgs, but in some cases we patch packages [NTL for example is patches with a patch that makes Singular's omalloc work] and having a vanilla NTL in those cases will cause crashes/odd behavior. Don't get me wrong on the above: We welcome packaging efforts, but I think the way we go with Debian is the better approach. As other people have seen: even changing something simple like to another version of gmp causes performance regressions in certain situations as well as plenty of doctest failures. You have been warned :) Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Packaging Sage
On 7/19/07, Georges Khaznadar <[EMAIL PROTECTED]> wrote: > William Stein a écrit : > > (1) Create a monolothic .deb, which installs everything SAGE currently > > distributes in /opt/sage/, along with a run script /usr/bin/sage. > > This stage is OK : the debian package was built finely, but it is done > using a brutal technique: everything is distributed, even .o files and > many other useless stuff. The resulting package is bloated (255 > megaBytes!) Why is it so big? It should be possible to make that package but have it be about 150MB. > I don't wish to uplod it anywhere, and prefer going on with stage 2 as > soon as possible. I would greatly appreciate it if we could finish stage 1 first, and really have it something that works well, can be distributed, etc. This would really be beneficial to many people, and as you have already demonstrated shouldn't be too difficult. > S I would like to ask you some questions in order to > save time and unnecessary trials: > > There must be some glue between Sage's core and the other packages like > Gap et Maxima, etc. As I aim to replace every part of Sage's current > package which was already packaged independently, by some modification of > the relevant glue component, so I would like to have some advice about it > if you can write it. > > For example, when I packaged Wims, which is now a package of Debian > Stable, I had to check that the file > /var/lib/wims/public_html/bin/maxima which is the wrapper used by Wims > to call Maxima was compatible with the current debian package already > existing. Fortunately, there were very few modifications to do inside > these glue components. Hopefully it may be similar for Sage? That's unlikely. Usually just using *anything* but the current version of maxima causes tons of problems, since they frequently make substantial changes to precision, special functions, etc. It's a surprisingly actively developed package. Mathematics software that wasn't meant to be used in library mode has a very very complicated interface that is often not very stable between versions of the software. That SAGE packages everything else in a monolithic fashion is perhaps the main technical reason SAGE is possible at all. That said, since you're unstoppable :-), each SAGE package (.spkg) is a tar.bz2 ball that has a file spkg-install in it, and a directory "patches" with all patches we make against the standard source tarball (actually, patches usually contains whole files instead of patches -- use diff to get an actual diff if you want one). > > (2) Only after having completely mastering (1), move on to considering > > breaking up SAGE into smaller packages and installing into the standard > > Debian environment. > > So I consider it now. If you want I can release the files > sage_2.6.orig.tar.gz (105557191 Bytes) and > sage_2.6-1.diff.gz ( 7633 Bytes) > > As you can see, the modification to debianise unproprely sage is very > lightweight. However I should make a more complete diff file to do it > following "the debian way" and make these sources yeld a more reasonably > sized binary package. Hence the call for your advice. Unfortunately (for your project) at the moment the SAGE distribution itself is undergoing some fairly extreme modifications as a result of several of the coding sprint projects at SAGE Days 4. We've added numerous new packages, and Didier Deshome did a bunch of great work designing a better structure for SAGE spkg's. The next version of SAGE (2.7.1), which I'll release tomorrow, will have all spkg's repackaged using this new structure. Also, it will have, hopefully, build much more reliably than SAGE-2.7, due to switching to g95 fortran. I would be extremely grateful if you could download sage-2.7.1 when I release it tomorrow, or look at http://sage.math.washington.edu/home/was/sage2.7.1/ which will be pretty close to what sage-2.7.1 will be. If nothing else, I would like any information about making a Debian SAGE package that you've come up with so far and would be willing to share. Thanks! By the way, would you like an account on sage.math.washington.edu? It's basically a big 16-core 64GB RAM server on which most sage developers have accounts. It helps greatly with sharing work. If so, write to me off-list. -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Packaging Sage
> Building SAGE on Linux/ARM at all is likely a major project. SAGE is quite > large and probably nobody has every compiled some of the key components > on Linux/ARM before. Because many of those components are very tightly coded > C (and sometimes assembly) mathematics libraries, there could be nontrivial > problems.Even getting SAGE to run on Linux Itanium is pretty > challenging; last time > I tried, I ran into a major bug in Python, where any use of readline > immediately > crashed Python. Debian packages don't have to be available on all architectures, see for example openoffice: http://packages.debian.org/unstable/editors/openoffice.org which is only available for amd64, i386, powerpc and sparc. So SAGE would be available only on those architectures it actually builds on. > > I am also not a DD (Debian Developer), but I created and got around 5 > > packages to Debian unstable already. > > > > But do you still need a sponsor? Yes, for every upload. But once you find one, it is usually very fast, because it only takes him a couple of seconds to upload a new version of the package. > It is more than security bugs, but overall the Debian people prefer > stability over features in stable. And that is certainly a valid choice > for many people. So what is a problem with maintaining a package in the stable? If SAGE doesn't have security issues, the maintainer doesn't have to fix anything. > I agree, but (at least it seems to me personally) too much politics has > not always served the Debian project well. I can understand the arguments > about non-free kernel modules (and I don't run them, because I avoid > buying that hardware), but (and this is only an example) the discussion of > stripping all non-free firmware (and not non-redistributable) out of the > kernel just lets me shake my head with wonders. In a similar matter it > boils down to "free software" vs. "open source" - to the outsider it > appears the same, but for the insider ... Well, I don't see this as a question of some idealism or whatsoever, but as a very practical question - am I allowed to fix bugs, see the sources, redistribute things etc (the main section), or not (non-free section). So I am glad they are very strict about this. The same with Firefox/Iceweasel - first I thought they went crazy, but when I thought about it, it is the right thing to do - if they cannot fix the sources of Firefox (without renaming it), then it cannot be in main, so they renamed it. > It reminds me of an old User Friendly the comic strip where after the > techies have been allowed to install Linux the management assumes that > they are happy, while it is revealed in the next pane that they are having > an argument which Linux distribution to install. Well, everyone his favourite. > Well, you can certainly make that argument, but other volunteer driven > distributions do not have that problem. I use Gentoo (besides OpenSuSE, > Fedora Core, and a couple more) and even though they all have their > problems Gentoo is community driven and releases 4 times a year. It isn't That's true. So where do you think the problem is? I am sorry it's a little off topic, but I am curious. It is actually not that much offtopic, because SAGE is in fact a distribution with a really formidable goal of working on all linuxes (and wmware). I myself just use the infrastructure of Debian, because all I do is to put sources for the package and Debian takes care of everything else - distribution, compilation, download, advertisement. Plus it has more than 1000 developers and many more people like me, so it is very convenient and powerful to "use" them, instead of doing things on my own. > always a smooth ride, but in life there are always tradeoffs. Debian has > profited immensely from Ubuntu (for example the KDE and Gnome packages > shipped in Sarge were pushed by Ubuntu developers) and lots of former > Debian developers nowadays work for and get paid by Ubuntu. And those > packages they work on end up in Debian unstable/testing, so Debian > certainly profits from Ubuntu, even though the general Slashdot tenor has > been for some time that Ubuntu is bleeding Debian dry. There is no doubt that Ubuntu helps Debian (and vice versa) and linux in general. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Packaging Sage
Ondrej Certik wrote: > Hello, >> >> current stable release on a whim, so I think getting Sage into Ubuntu >> is >> >> a >> >> much more reachable goal. It also seems that Ubuntu is getting a lot >> >> more >> >> mindshare in the *desktop* these days (compared to Debian unstable). >> >> I meant Debian *stable* in the end, not *unstable* > > That is certainly true. > >> Disclaimer: I can only describe from what I saw happening on the LyX and >> ATLAS mailing lists. I have never been a Debian packager/developer nor >> have I ever applied to be one, so I might be mistaken about several >> issues. > > I am also not a DD (Debian Developer), but I created and got around 5 > packages to Debian unstable already. > But do you still need a sponsor? >> >> Well, Debian supports a lot more architectures and from what I know it >> is >> discouraged to limit the architecture due to non-technical reasons. Sage >> is widely used on Linux and x86, x86-64 and to some extend on PPC and >> Itanic, but what about the other 9 or so architectures Debian supports? >> They provide build infrastructure, but who would care about Sage on >> Linux/ARM? > > If noone is using it, than no bugs will be filled against it I guess. > And if it doesn't even build, that's of course another issue. But that > usually signals that something is wrong. > >> The other issue I have seen was that in stable you had to patch bugs, >> not >> add features. Specfically: When LyX 1.4.4 came out the Debian stable >> package was still 1.4.2, so instead of upgrading to 1.4.4 wholesale the >> maintainer had to pick the patches out that fixed bugs and to apply >> them. > > I thought only the vulnerability bugs are fixed in the stable > distribution. Well, that of course is an issue. But isn't the same > problem in Ubuntu then? > Yes, I believe so, but the greater release frequency would compensate to some extent. Overall the question whether Sage should be part of the distribution or whether there should be packages provided for distributions. I think that external packages just provide more flexibility and it is a prerequisite for distribution packages (in monolithic form or whatever) anyway. >> > It actually has the advantage of being both in Debian and >> > Ubuntu as it gets to Ubuntu automatically. >> >> That is certainly true, but I do not believe that William's scenario (2) >> will happen anytime soon. I believe that Sage can live just fine with >> scenario (1). > > Debian doesn't allow the scenario (1) (officially), but I thought > Ubuntu also doesn't. > Probably not, I would be surprised íf they did. A 150MB package that would be considered non-essential by most users probably wouldn't be on the disc images anyway, so providing it someplace else for download wouldn't make much of a difference. >> And looking at the pace of Sage releases: Who would want to work with >> the >> Sage released 1.5 years ago? Who would maintain such old releases? That >> and the (more or less) reliable 6 months release time frame of Ubuntu >> could make the (potential) synchronisation of Sage releases a lot more >> plannable, because who knows when the next Debian stable will come. I >> use >> to admin some boxes with Debian stable a long time ago and the >> neverending >> wait for Woody (finally released in 2002) made me switch distributions. >> Sarge came along nearly 3 years later, so the release frequency of >> Ubuntu >> has been higher than 3 times that of Debian stable. > > I really thought only the security bugs are fixed in the stable, > otherwise the packages are untouched. But I've been only using > unstable for last couple of years... Of course it doesn't make sense > to maintain old releases, but I think it is not necessary. So please > correct me if I am wrong. > It is more than security bugs, but overall the Debian people prefer stability over features in stable. And that is certainly a valid choice for many people. >> And some of the discussion regarding the removal on non-free >> documentation >> out of debian (I believe it was the glibc doc among other things) makes >> my >> head spin. The issue was postponed to get Sarge out of the door, but >> still. Alas, I don't want to start a flame war about Linux >> distributions, >> so anybody who feels offended please correct me offlist or put me in >> your >> kill file :) > > I think the flamewar only happens when people don't know how (or don't > want) to discuss. I think it's very good that Debian distinguishes > main and non-free, because I am always sure that when I install main, > I have all the rights are described in the Debian Free Software > Guidelines (DFSG). And the non-free is there for things that I need > (like wireless things, some documentation, google earth, ...) -- but > it reminds me that those programs are not free and thus I should be > aware that if I depend on them too much, I could easily get stuck > depending on something that I am not allowed to fix or use freely. I > think it's v
[sage-devel] Re: Packaging Sage
On 7/17/07, Ondrej Certik <[EMAIL PROTECTED]> wrote: > > Well, Debian supports a lot more architectures and from what I know it is > > discouraged to limit the architecture due to non-technical reasons. Sage > > is widely used on Linux and x86, x86-64 and to some extend on PPC and > > Itanic, but what about the other 9 or so architectures Debian supports? > > They provide build infrastructure, but who would care about Sage on > > Linux/ARM? > > If noone is using it, than no bugs will be filled against it I guess. > And if it doesn't even build, that's of course another issue. But that > usually signals that something is wrong. Building SAGE on Linux/ARM at all is likely a major project. SAGE is quite large and probably nobody has every compiled some of the key components on Linux/ARM before. Because many of those components are very tightly coded C (and sometimes assembly) mathematics libraries, there could be nontrivial problems.Even getting SAGE to run on Linux Itanium is pretty challenging; last time I tried, I ran into a major bug in Python, where any use of readline immediately crashed Python. > > > It actually has the advantage of being both in Debian and > > > Ubuntu as it gets to Ubuntu automatically. > > > > That is certainly true, but I do not believe that William's scenario (2) > > will happen anytime soon. I believe that Sage can live just fine with > > scenario (1). > > Debian doesn't allow the scenario (1) (officially), but I thought > Ubuntu also doesn't. Good point/question. When suggesting (1) I only meant that the .deb would be distributed from sagemath mirrors, or an apt repository that we setup. > > And some of the discussion regarding the removal on non-free documentation > > out of debian (I believe it was the glibc doc among other things) makes my > > head spin. The issue was postponed to get Sarge out of the door, but > > still. Alas, I don't want to start a flame war about Linux distributions, > > so anybody who feels offended please correct me offlist or put me in your > > kill file :) > > I think the flamewar only happens when people don't know how (or don't > want) to discuss. I think it's very good that Debian distinguishes > main and non-free, because I am always sure that when I install main, > I have all the rights are described in the Debian Free Software > Guidelines (DFSG). And the non-free is there for things that I need > (like wireless things, some documentation, google earth, ...) -- but > it reminds me that those programs are not free and thus I should be > aware that if I depend on them too much, I could easily get stuck > depending on something that I am not allowed to fix or use freely. I > think it's very cleverly invented. I completely agree that there is huge longterm value in how careful Debian is in distinguishing free/non-free. William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Packaging Sage
> >> current stable release on a whim, so I think getting Sage into Ubuntu is > >> a > >> much more reachable goal. It also seems that Ubuntu is getting a lot > >> more > >> mindshare in the *desktop* these days (compared to Debian unstable). > > I meant Debian *stable* in the end, not *unstable* That is certainly true. > Disclaimer: I can only describe from what I saw happening on the LyX and > ATLAS mailing lists. I have never been a Debian packager/developer nor > have I ever applied to be one, so I might be mistaken about several > issues. I am also not a DD (Debian Developer), but I created and got around 5 packages to Debian unstable already. > > Well, Debian supports a lot more architectures and from what I know it is > discouraged to limit the architecture due to non-technical reasons. Sage > is widely used on Linux and x86, x86-64 and to some extend on PPC and > Itanic, but what about the other 9 or so architectures Debian supports? > They provide build infrastructure, but who would care about Sage on > Linux/ARM? If noone is using it, than no bugs will be filled against it I guess. And if it doesn't even build, that's of course another issue. But that usually signals that something is wrong. > The other issue I have seen was that in stable you had to patch bugs, not > add features. Specfically: When LyX 1.4.4 came out the Debian stable > package was still 1.4.2, so instead of upgrading to 1.4.4 wholesale the > maintainer had to pick the patches out that fixed bugs and to apply them. I thought only the vulnerability bugs are fixed in the stable distribution. Well, that of course is an issue. But isn't the same problem in Ubuntu then? > > It actually has the advantage of being both in Debian and > > Ubuntu as it gets to Ubuntu automatically. > > That is certainly true, but I do not believe that William's scenario (2) > will happen anytime soon. I believe that Sage can live just fine with > scenario (1). Debian doesn't allow the scenario (1) (officially), but I thought Ubuntu also doesn't. > And looking at the pace of Sage releases: Who would want to work with the > Sage released 1.5 years ago? Who would maintain such old releases? That > and the (more or less) reliable 6 months release time frame of Ubuntu > could make the (potential) synchronisation of Sage releases a lot more > plannable, because who knows when the next Debian stable will come. I use > to admin some boxes with Debian stable a long time ago and the neverending > wait for Woody (finally released in 2002) made me switch distributions. > Sarge came along nearly 3 years later, so the release frequency of Ubuntu > has been higher than 3 times that of Debian stable. I really thought only the security bugs are fixed in the stable, otherwise the packages are untouched. But I've been only using unstable for last couple of years... Of course it doesn't make sense to maintain old releases, but I think it is not necessary. So please correct me if I am wrong. > And some of the discussion regarding the removal on non-free documentation > out of debian (I believe it was the glibc doc among other things) makes my > head spin. The issue was postponed to get Sarge out of the door, but > still. Alas, I don't want to start a flame war about Linux distributions, > so anybody who feels offended please correct me offlist or put me in your > kill file :) I think the flamewar only happens when people don't know how (or don't want) to discuss. I think it's very good that Debian distinguishes main and non-free, because I am always sure that when I install main, I have all the rights are described in the Debian Free Software Guidelines (DFSG). And the non-free is there for things that I need (like wireless things, some documentation, google earth, ...) -- but it reminds me that those programs are not free and thus I should be aware that if I depend on them too much, I could easily get stuck depending on something that I am not allowed to fix or use freely. I think it's very cleverly invented. The only problem is that because Debian is only developed by volunteers, some things are quite slow, and that's where Ubuntu comes in. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Packaging Sage
Ondrej Certik wrote: > >> While solution (1) is against the "Debian Way" (2) is next to impossible >> from a debugging standpoint, i.e. which version of libSingular, g++ and >> clisp are you using? I don't think anybody intends to get Sage into the >> official Debian distribution because maintaining a stable branch release >> has some rather unpleasant limitations. You can't just bump up to the >> current stable release on a whim, so I think getting Sage into Ubuntu is >> a >> much more reachable goal. It also seems that Ubuntu is getting a lot >> more >> mindshare in the *desktop* these days (compared to Debian unstable). I meant Debian *stable* in the end, not *unstable* > Hello > Could you please elaborate more on what limitations there are in > Debian to maintain the package in the stable branch? Disclaimer: I can only describe from what I saw happening on the LyX and ATLAS mailing lists. I have never been a Debian packager/developer nor have I ever applied to be one, so I might be mistaken about several issues. > It seems to me, > that getting the package to unstable is the same work as getting it to > Ubuntu. Well, Debian supports a lot more architectures and from what I know it is discouraged to limit the architecture due to non-technical reasons. Sage is widely used on Linux and x86, x86-64 and to some extend on PPC and Itanic, but what about the other 9 or so architectures Debian supports? They provide build infrastructure, but who would care about Sage on Linux/ARM? The other issue I have seen was that in stable you had to patch bugs, not add features. Specfically: When LyX 1.4.4 came out the Debian stable package was still 1.4.2, so instead of upgrading to 1.4.4 wholesale the maintainer had to pick the patches out that fixed bugs and to apply them. It might be possible to update to a new minor version in stable, but it seems to be discouraged. Now LyX isn't exactly moving fast, but can you imagine that with Sage's release frequence? (Potshot: Not at the moment ;)) > It actually has the advantage of being both in Debian and > Ubuntu as it gets to Ubuntu automatically. That is certainly true, but I do not believe that William's scenario (2) will happen anytime soon. I believe that Sage can live just fine with scenario (1). > And as to the propagation > to the stable release of either Debian or Ubuntu, it seems to me it is > the same in both distributions - only Ubuntu releases three times more > often. And looking at the pace of Sage releases: Who would want to work with the Sage released 1.5 years ago? Who would maintain such old releases? That and the (more or less) reliable 6 months release time frame of Ubuntu could make the (potential) synchronisation of Sage releases a lot more plannable, because who knows when the next Debian stable will come. I use to admin some boxes with Debian stable a long time ago and the neverending wait for Woody (finally released in 2002) made me switch distributions. Sarge came along nearly 3 years later, so the release frequency of Ubuntu has been higher than 3 times that of Debian stable. And some of the discussion regarding the removal on non-free documentation out of debian (I believe it was the glibc doc among other things) makes my head spin. The issue was postponed to get Sarge out of the door, but still. Alas, I don't want to start a flame war about Linux distributions, so anybody who feels offended please correct me offlist or put me in your kill file :) > > Ondrej > Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Packaging Sage
> While solution (1) is against the "Debian Way" (2) is next to impossible > from a debugging standpoint, i.e. which version of libSingular, g++ and > clisp are you using? I don't think anybody intends to get Sage into the > official Debian distribution because maintaining a stable branch release > has some rather unpleasant limitations. You can't just bump up to the > current stable release on a whim, so I think getting Sage into Ubuntu is a > much more reachable goal. It also seems that Ubuntu is getting a lot more > mindshare in the *desktop* these days (compared to Debian unstable). Could you please elaborate more on what limitations there are in Debian to maintain the package in the stable branch? It seems to me, that getting the package to unstable is the same work as getting it to Ubuntu. It actually has the advantage of being both in Debian and Ubuntu as it gets to Ubuntu automatically. And as to the propagation to the stable release of either Debian or Ubuntu, it seems to me it is the same in both distributions - only Ubuntu releases three times more often. Ondrej --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Packaging Sage
William Stein wrote: > > On 7/17/07, Georges Khaznadar <[EMAIL PROTECTED]> wrote: >> Hello, I would like to make a Debian package of Sage. >> >> I recently attended a talk of Professor Tsai who uses it in Taiwan, and >> it was pretty convincing. >> >> Apparently, Sage depends on other software which should be packaged >> separately, according to the "Debian way". With the source packages, the >> dependencies were solved by including the other software's sources in >> the tree. I already noticed such habits in other upstrean packages I >> have "debianised" recently. >> >> Please have you any hint of interesting informations about the relations >> between the development of Sage and the other packages it depends on? > > Creating a .deb for SAGE has been discussed a few times on sage-devel, > so there is definitely strong interest in doing it. Probably people have > attempted it 4 times now, but everybody has failed, except Bobby Moretti > one year ago (who unfortunately didn't maintain what he did). If you want > to succeed at making a SAGE .deb, here is what you'll likely do: > > (1) Create a monolothic .deb, which installs everything SAGE currently > distributes in /opt/sage/, along with a run script /usr/bin/sage. > Basically > this involves modifying the make file in the SAGE source > distribution so that it works with the Debian packaging tools. Bobby > (who I've cc'd), might be kind enough to give you further tips. > I looked into (1) (also for rpm) a while ago and came up with pkgwrite - see http://ffem.org/daveb/pkgwrite/ - this is a perl script that creates debs or rpms from the same config file. I mostly lurk on sage-devel these days because work barely leaves me time to play around with sage :( While solution (1) is against the "Debian Way" (2) is next to impossible from a debugging standpoint, i.e. which version of libSingular, g++ and clisp are you using? I don't think anybody intends to get Sage into the official Debian distribution because maintaining a stable branch release has some rather unpleasant limitations. You can't just bump up to the current stable release on a whim, so I think getting Sage into Ubuntu is a much more reachable goal. It also seems that Ubuntu is getting a lot more mindshare in the *desktop* these days (compared to Debian unstable). Cheers, Michael > (2) Only after having completely mastering (1), move on to considering > breaking up SAGE into smaller packages and installing into the standard > Debian environment. > > Most people are extremely reluctant to do (1), because it violates the > "Debian way". > It is however, *definitely* the right first thing to do, and has > substantial > benefits over the tarball/source distribution we are currently > distributing, > so it is well worth doing. > > Note that in (1), creating the .deb package > should be so easy that any user with SAGE installed from source and > all the appropriate > Debian package tools should be able to just type "sage -pkg_deb foo.deb" > and get a Debian package. This ease is critical for long term > maintainability. > > Doing (2) is probably way way too much work for anybody who couldn't > easily > do (1), which is another argument for doing (1) first. Anybody who could > do (2) > could easily do (1), and doing (1) would actually work and have great > benefit > to SAGE users; most typical mathematicians wouldn't > notice any difference between (1) and (2), even though (2) is vastly more > difficult. > > Thanks for any help!! > > -- William > --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
[sage-devel] Re: Packaging Sage
On 7/17/07, Georges Khaznadar <[EMAIL PROTECTED]> wrote: > Hello, I would like to make a Debian package of Sage. > > I recently attended a talk of Professor Tsai who uses it in Taiwan, and > it was pretty convincing. > > Apparently, Sage depends on other software which should be packaged > separately, according to the "Debian way". With the source packages, the > dependencies were solved by including the other software's sources in > the tree. I already noticed such habits in other upstrean packages I > have "debianised" recently. > > Please have you any hint of interesting informations about the relations > between the development of Sage and the other packages it depends on? Creating a .deb for SAGE has been discussed a few times on sage-devel, so there is definitely strong interest in doing it. Probably people have attempted it 4 times now, but everybody has failed, except Bobby Moretti one year ago (who unfortunately didn't maintain what he did). If you want to succeed at making a SAGE .deb, here is what you'll likely do: (1) Create a monolothic .deb, which installs everything SAGE currently distributes in /opt/sage/, along with a run script /usr/bin/sage. Basically this involves modifying the make file in the SAGE source distribution so that it works with the Debian packaging tools. Bobby (who I've cc'd), might be kind enough to give you further tips. (2) Only after having completely mastering (1), move on to considering breaking up SAGE into smaller packages and installing into the standard Debian environment. Most people are extremely reluctant to do (1), because it violates the "Debian way". It is however, *definitely* the right first thing to do, and has substantial benefits over the tarball/source distribution we are currently distributing, so it is well worth doing. Note that in (1), creating the .deb package should be so easy that any user with SAGE installed from source and all the appropriate Debian package tools should be able to just type "sage -pkg_deb foo.deb" and get a Debian package. This ease is critical for long term maintainability. Doing (2) is probably way way too much work for anybody who couldn't easily do (1), which is another argument for doing (1) first. Anybody who could do (2) could easily do (1), and doing (1) would actually work and have great benefit to SAGE users; most typical mathematicians wouldn't notice any difference between (1) and (2), even though (2) is vastly more difficult. Thanks for any help!! -- William --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~--~~~~--~~--~--~---
