From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Fggjh-0005Vv-6O for garchives@archives.gentoo.org; Thu, 18 May 2006 11:32:09 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4IBT98m018767; Thu, 18 May 2006 11:29:09 GMT Received: from crossford.net (dsl-62-3-120-141.zen.co.uk [62.3.120.141]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4IBMT6P026360 for ; Thu, 18 May 2006 11:22:29 GMT Received: (qmail 18557 invoked from network); 18 May 2006 12:27:26 +0100 Received: from unknown (HELO spike) (192.168.100.18) by 192.168.10.10 with SMTP; 18 May 2006 12:27:26 +0100 Date: Thu, 18 May 2006 12:22:30 +0100 From: Roy Bamford Subject: Re: [gentoo-dev] Paludis and Profiles To: gentoo-dev@lists.gentoo.org References: <20060516161549.442b4d8a@localhost> In-Reply-To: <20060516161549.442b4d8a@localhost> (from spb@gentoo.org on Tue May 16 16:15:49 2006) X-Mailer: Balsa 2.3.8 Message-Id: <1147951350l.9558l.0l@spike> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by robin.gentoo.org id k4IBMT6P026360 X-Archives-Salt: 6e495d33-6e09-4eaf-8d31-2ea55f21ad0f X-Archives-Hash: fdd3eea78331d88229005e3ec3178cb3 On 2006.05.16 16:15, Stephen Bennett wrote: > If noone has any strong reasonable objections, I'd like to add a > Paludis profile to the tree. This would use Paludis as the default > provider for virtual/portage (which is a less than ideal name, but > that > is another discussion entirely), and provide ebuild devs with a place > where they can try out some of our profile enhancements should they > want to. It is worth noting on the last point that most of these are > long-standing Portage feature requests, at least some of which are > planned for inclusion in Portage at some point in the future. This > would allow devs access to them earlier, as a sort of testbed. > > The next question is where to put it. The options as I see them are > under default-linux/x86/ or in a top-level paludis/ a la hardened, > selinux, embedded, and the like. The latter is easier to exclude for > those worried about tree size, though the impact there should be > minimal. Neither way produces significantly more duplication, since we > can make use of multiple profile inheritance. If anyone has any > preference or other input, I'd like to hear it. > > That's my proposal. The benefits I like to think are obvious. The > drawbacks are, as far as I can see, in tree size, which should be > minimal. Those concerned about local tree size can exclude it, and for > size on the mirrors it's trivial compared to the rest of the tree. > > Comments? > -- > gentoo-dev@gentoo.org mailing list Hi all, Being new to this list and having read every post since just before this discussion started, I feel its time for a generic summing up. There are a number of interesting questions arising from the thread along the lines of 1) Should the Gentoo tree support alternative package managers at all? 2) Should the tree be changed to enable experimental support to be added for alternative package managers? 3) Do alternative package managers have to be (at least) backwards compatible with Portage? 4) Should Portage be replaced by one (or more) of the alternatives? I'm deliberately avoiding the use of any names because Portage is the incumbent package manager and the questions have only been raised by one alternative package manager *so far*. Question 1) and 2) can be answered in the same breath. If its decided that alternative package managers will be supported then any required changes to make that possible are inferred, if indeed, its not actually possible at the moment. 1) is really a political/policy question, not a software engineering question, so should be determined by the council. 3) The answer has to be, as a minimum, alternate package managers need to be able to build on what Portage has already installed. That is, be backwards compatible. There is no need for users to have an 'undo' feature short of a reinstall. Experimental packages are just that, if you really might not be able to take the consequences, don't experiment. That's no different than for any other package now. 4) This does not even arise until satisfactory answers have been obtained to 1) and 2) and any potential Portage replacement has undergone a period of testing. However, there has to be a a way of migrating the user base to any new package manager should Portage become depreciated. Again, just like any other package. When alternate package manager(s) are proved to safely (no worse than portage) do everything from install to maintenance, there may be an interim stage where users can choose to install using package manager 'A' or package manager 'B', knowing that they cannot switch without a reinstall. There is no package in the tree that is sacrosanct - not even Portage. Gentoo must evolve (all of it) or die. The process is all self evident, its the same process that's followed for every other package in the tree. You probably don't want my views but here they are anyway. 1) Yes - packages managers are just packages, like every other package. 2) Yes - in a generic way. No special concessions to any particular package manager. I know its not like that at the moment because Portage defined Gentoo. Looking into the distant future, we can expect Package Managers to be replaced like other packages. 3) I'm ambivalent - I'm a user not a dev. 4) Only time will tell. Regards, Roy Bamford (NeddySeagoon) -- gentoo-dev@gentoo.org mailing list