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