1 |
Hi, |
2 |
Thank you for the explanation: I kind of guessed that some part of sage were |
3 |
omitted to adapt the two packaging system but your explanation gave me the |
4 |
details I was missing. |
5 |
As you said the combinat queue is/should be a real mess of continuous |
6 |
updates (at least this is what I was told) so I am not entirely sure how well |
7 |
an e-build would perform, in case you decide to spend some time on it I will |
8 |
gladly be a guinea pig for testing it out. |
9 |
I do not understand sage package system in details so my request may just be |
10 |
stupid but is it possible to produce separate ebuilds for the different part |
11 |
of sage that are now stripped? If not for all of those can this be done for the |
12 |
various packages in $SAGE_ROOT/devel ? If an e-build is not feasible, can |
13 |
USE flags be used to select which extensions to include at compile time? |
14 |
Thank you |
15 |
S. |
16 |
|
17 |
|
18 |
* fbissey@××××××××××××.nz <fbissey@××××××××××××.nz> [2011-08-09 16:29:52]: |
19 |
|
20 |
> Quoting VulK <etn45p4m@×××××.com>: |
21 |
> |
22 |
> > Dear all, |
23 |
> > this is my first post to gentoo-science and I am writing because I have some |
24 |
> > problems running experimental code from the sage project. |
25 |
> > My issue is the following: |
26 |
> > I have sci-mathematics/sage-4.7-r2 installed from the sage-on-gentoo overlay |
27 |
> > and I would like to install the combinat queue; I am following these |
28 |
> > instructions: http://wiki.sagemath.org/combinat/MercurialStepByStep |
29 |
> > The command I am supposed to run is |
30 |
> > # sage -combinat install |
31 |
> > unfortunately -combinat is not recognized by sage as a valid option. I |
32 |
> > browsed a little bit around the filesystem and I noticed that $SAGE_ROOT is |
33 |
> > empty (except for some documentation) while on other installations of sage |
34 |
> > (not using the ebuilds) there is plenty of stuff including a devel/combinat |
35 |
> > folder. |
36 |
> > Is there an option I can use when installing sage to allow for experimental |
37 |
> > sources? or is there any other way I can use queues without installing sage |
38 |
> > not using portage? |
39 |
> > Thanks |
40 |
> > VulK |
41 |
> > |
42 |
> > PS: some weird behaviour: |
43 |
> > |
44 |
> > % sage -h |
45 |
> > ---------------------------------------------------------------------- |
46 |
> > | Sage Version 4.7, Release Date: 2011-05-23 | |
47 |
> > ---------------------------------------------------------------------- |
48 |
> > |
49 |
> > Optional arguments: |
50 |
> > file.<sage|py|spyx> -- run given .sage, .py or .spyx files |
51 |
> > -advanced -- list all command line options |
52 |
> > -c <cmd> -- Evaluates cmd as sage code |
53 |
> > -experimental -- list all experimental packages that can be installed |
54 |
> > -gap [...] -- run Sage's Gap with given arguments |
55 |
> > -gp [...] -- run Sage's PARI/GP calculator with given arguments |
56 |
> > -h, -? -- print this help message |
57 |
> > -i [packages] -- install the given Sage packages |
58 |
> > -inotebook [...] -- start the *insecure* Sage notebook |
59 |
> > -maxima [...] -- run Sage's Maxima with given arguments |
60 |
> > -mwrank [...] -- run Sage's mwrank with given arguments |
61 |
> > -n, -notebook [...] -- start the Sage notebook (options are the same |
62 |
> > as for the notebook command in Sage) |
63 |
> > -optional -- list all optional packages that can be installed |
64 |
> > -python [...] -- run the Python interpreter |
65 |
> > -R [...] -- run Sage's R with given arguments |
66 |
> > -singular [...] -- run Sage's singular with given arguments |
67 |
> > -root -- print the Sage root directory |
68 |
> > -t [options] <files|dir> |
69 |
> > -- test examples in .py, .pyx, .sage or .tex files |
70 |
> > options: |
71 |
> > -long -- include lines with the phrase |
72 |
> > 'long time' |
73 |
> > -verbose -- print debugging output during |
74 |
> > the test |
75 |
> > -optional -- also test all #optional examples |
76 |
> > -only-optional <tag1,...,tagn> -- only run tests |
77 |
> > including one of the #optional tags |
78 |
> > -randorder[=seed] -- randomize order of tests |
79 |
> > -v, -version -- print the Sage version |
80 |
> > |
81 |
> > % sage -experimental |
82 |
> > sage-run received unknown option: -experimental |
83 |
> > usage: sage [options] |
84 |
> > Try 'sage -h' for more information. |
85 |
> |
86 |
> Hi VuLK, |
87 |
> |
88 |
> unfortunately at this stage we do not support that in sage-on-gentoo. |
89 |
> Actually the version we ship is stripped down in some ways. |
90 |
> Let me explain: |
91 |
> sage has its own upgrade system, it wouldn't work in the kind of |
92 |
> installation we |
93 |
> do and that would mean changing, adding and deleting files in the |
94 |
> system outside |
95 |
> the control of the package manager. We definitely don't want to do that. So we |
96 |
> removed the options for sage upgrade. The only option to upgrade is |
97 |
> portage/package-core etc... |
98 |
> |
99 |
> There are options to help you create spkg, install spkg and so on, we could |
100 |
> probably give back the one to create spkg but we otherwise completely |
101 |
> circumvent the sage build system so the corresponding options are gone. |
102 |
> |
103 |
> The main problem is that sage's normal distribution model is trying to be |
104 |
> developer friendly but isn't distro friendly. We coerced it into a |
105 |
> distro which |
106 |
> makes it more appealing for an end user to try but it is stripped of |
107 |
> some of the |
108 |
> dev-friendly features. |
109 |
> |
110 |
> There are advantages and disadvantages for both models. We can be/are |
111 |
> more up to |
112 |
> date than sage with some packages. If I patch something I literally have to |
113 |
> reinstall the whole of of the sage spkg from portage, the equivalent of sage |
114 |
> -ba while from vanilla sage you could use sage -b and only rebuild the |
115 |
> necessary bits. |
116 |
> |
117 |
> Now you are the first person making this kind of request about using something |
118 |
> like the combinat queue. We probably can give you an ebuild pulling the |
119 |
> combinat queue. There are just two caveats here: |
120 |
> 1) it may take a bit of time for us to come up with something. |
121 |
> 2) because I expect the queue to be somewhat in flux it would have to be a hot |
122 |
> ebuild of some kind. If you can live with that we can probably work something |
123 |
> out. |
124 |
> |
125 |
> Francois |
126 |
> |
127 |
> |
128 |
> |
129 |
> |