Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-science
Navigation:
Lists: gentoo-science: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: <gentoo-science@g.o>
From: Christopher Schwan <cschwan@...>
Subject: Re: sage queues
Date: Tue, 9 Aug 2011 13:46:30 +0200
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 (...site-packages/sage 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


References:
sage queues
-- VulK
Re: sage queues
-- fbissey
Re: sage queues
-- VulK
Navigation:
Lists: gentoo-science: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: sage queues
Next by thread:
la files for sci-libs/mpir
Previous by date:
Re: sage queues
Next by date:
Re: sage queues


Updated Jul 05, 2012

Summary: Archive of the gentoo-science mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.