From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Qqklp-0005WY-3z for garchives@archives.gentoo.org; Tue, 09 Aug 2011 11:46:55 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 69BA121C075; Tue, 9 Aug 2011 11:46:42 +0000 (UTC) Received: from mailgate-02.zdv.uni-mainz.de (mailgate-02.zdv.Uni-Mainz.DE [134.93.178.246]) by pigeon.gentoo.org (Postfix) with ESMTP id 59F7421C06E for ; Tue, 9 Aug 2011 11:46:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=cschwan@students.uni-mainz.de; q=dns/txt; s=ironport; t=1312890391; x=1344426391; h=from:to:subject:date:message-id:in-reply-to:references: mime-version:content-transfer-encoding; bh=5y7HfW6hTloo/4Xryy9xPl5gAkjgcfDMaie+OewvRdQ=; b=Ze+lAnUEIOAGOeN4ewSKBv1PmiTqhJ2OEIR5k/0DnYlUM43v917IrB8K eB2SqjseObeUtPRXXaU02IwySd7hMn9YQ2tSuzr01Nh7tezCYxPYEMvgZ DZ52St7eCBTznFQjEfQIpqIf4mUIgA10ssnXqeqrIfXNdv9RyVGsCWnxf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtcfALQcQU4KXgZY/2dsb2JhbABChn2RIpAQgUABAQU6TwsYCRUQDwFHBsUrhkYEmBeLWw Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-02.zdv.uni-mainz.de with ESMTP; 09 Aug 2011 13:46:30 +0200 Received: from cschwan-laptop.localnet (134.93.86.199) by mail.uni-mainz.de (10.94.6.90) with Microsoft SMTP Server (TLS) id 14.1.289.1; Tue, 9 Aug 2011 13:46:30 +0200 From: Christopher Schwan To: Subject: Re: [gentoo-science] sage queues Date: Tue, 9 Aug 2011 13:46:30 +0200 Message-ID: <2556619.zYccKqItmZ@cschwan-laptop> User-Agent: KMail/4.7.0 (Linux/2.6.39-gentoo-r3; KDE/4.7.0; x86_64; ; ) In-Reply-To: <20110809050744.GF24561@mistaya.nunet.neu.edu> References: <20110809030859.GE24561@mistaya.nunet.neu.edu> <20110809162952.nn4s0c4048sscww0@webmail.slingshot.co.nz> <20110809050744.GF24561@mistaya.nunet.neu.edu> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-science@lists.gentoo.org Reply-to: gentoo-science@lists.gentoo.org MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Originating-IP: [134.93.86.199] X-Archives-Salt: X-Archives-Hash: 72f76e008ad045d0a346760d847dd8ad 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