Gentoo Archives: gentoo-science

From: Christopher Schwan <cschwan@××××××××××××××××××.de>
To: gentoo-science@l.g.o
Subject: Re: [gentoo-science] sage queues
Date: Tue, 09 Aug 2011 11:46:55
Message-Id: 2556619.zYccKqItmZ@cschwan-laptop
In Reply to: Re: [gentoo-science] sage queues by VulK
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.
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.
24 Lets assume its done, then I see the following pros and cons:
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
32 Con:
33 - Upgrading is much more difficult, because the number of packages that need a
34 bump would be much higher ( 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.
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?
45 Cheers,
46 Christopher