1 |
On Tuesday 09 August 2011 01:07:44 you wrote: |
2 |
> Hi, |
3 |
> Thank you for the explanation: I kind of guessed that some part of sage were |
4 |
> omitted to adapt the two packaging system but your explanation gave me the |
5 |
> details I was missing. |
6 |
> As you said the combinat queue is/should be a real mess of continuous |
7 |
> updates (at least this is what I was told) so I am not entirely sure how |
8 |
> well an e-build would perform, in case you decide to spend some time on it |
9 |
> I will gladly be a guinea pig for testing it out. |
10 |
> I do not understand sage package system in details so my request may just be |
11 |
> stupid but is it possible to produce separate ebuilds for the different |
12 |
> part of sage that are now stripped? If not for all of those can this be |
13 |
> done for the various packages in $SAGE_ROOT/devel ? If an e-build is not |
14 |
> feasible, can USE flags be used to select which extensions to include at |
15 |
> compile time? Thank you |
16 |
> S. |
17 |
|
18 |
If I understand you correctly, you are asking if it is possible to further |
19 |
split up the sage ebuild, so that we have individual ebuilds for |
20 |
sage.combinat, sage.interfaces and so on. That would make it possible to |
21 |
replace individual parts by development versions (which is your original aim) |
22 |
- very interesting idea. |
23 |
|
24 |
Lets assume its done, then I see the following pros and cons: |
25 |
|
26 |
Pro: |
27 |
- The option to leave out certain packages and thereby the possiblity to lower |
28 |
the number of dependencies (that was my long-term goal) |
29 |
- Recompiliation of Sage (because of the addition of some patches) would take |
30 |
less time |
31 |
|
32 |
Con: |
33 |
- Upgrading is much more difficult, because the number of packages that need a |
34 |
bump would be much higher (...site-packages/sage currently has 42 |
35 |
subdirectories). Maybe we will then need some automatization |
36 |
- The number of patches we apply to Sage is quite high, also the number of |
37 |
lines of code (additional sed patches). By splitting up the big Sage ebuild we |
38 |
decentralize this and I fear the overall number of patches will rise - |
39 |
although the new ebuilds will be relatively small, I think. |
40 |
|
41 |
I don't know how difficult this split is, but I am tempted to do this. What do |
42 |
you think of it, Francois? DId you already tried something similar with sage- |
43 |
prefix? |
44 |
|
45 |
Cheers, |
46 |
Christopher |