From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16653 invoked from network); 2 Dec 2004 16:12:30 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 2 Dec 2004 16:12:30 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.41) id 1CZtZF-00073X-PI for arch-gentoo-portage-dev@lists.gentoo.org; Thu, 02 Dec 2004 16:12:29 +0000 Received: (qmail 21679 invoked by uid 89); 2 Dec 2004 16:12:27 +0000 Mailing-List: contact gentoo-portage-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail Reply-To: gentoo-portage-dev@lists.gentoo.org X-BeenThere: gentoo-portage-dev@gentoo.org Received: (qmail 14016 invoked from network); 2 Dec 2004 16:12:27 +0000 From: Brian Harring Reply-To: ferringb@gentoo.org To: gentoo-portage-dev@lists.gentoo.org In-Reply-To: <200412021349.18285.pauldv@gentoo.org> References: <20041201175509.GA32317@darkalpt> <200412011922.56841.luke-jr@utopios.org> <13cc2f7804120113147a82254b@mail.gmail.com> <200412021349.18285.pauldv@gentoo.org> Content-Type: text/plain Date: Thu, 02 Dec 2004 08:11:12 -0800 Message-Id: <1102003872.419.39.camel@exodus> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-portage-dev] The merge of emerde with emerge X-Archives-Salt: 4bf8b2d7-bb49-4ae2-8aba-c16ea1f80675 X-Archives-Hash: a5629954af4d23a159444377fb61bb51 On Thu, 2004-12-02 at 13:49 +0100, Paul de Vrieze wrote: > On Wednesday 01 December 2004 22:14, Colin Kingsley wrote: > > > > > > emerge $(cat pfile) > > > > Stop being pedantic. Clearly, the point of this function is to make it > > easy to perform actions on large groups of packages without shell > > magic. > > What's wrong with shell magic? It defines unix. Gentoo is not in the > business of making MsWormOS Throwing in my 2 cents on this lil ^^^ bit of nastyness, kindly save us our sanity and avoid the fud. Argue your point w/out resorting to it please. Unless you're intending on somehow linking a command line _argument_ option to ms's swiss cheese implementations- in which case, feel free to attempt it. I'm sure it would be a good laugh. > > > A better idea would be to convert GRPs to Slackware tgz > > > > How would this be any different? or better? I'd say the ability to > > create, as well as install third party packages is kind of nifty. Why > > would it be better to convert a Gentoo package instead of natively > > creating the .tgz? > > Converting .tbz2 packages means that the problems are split up. In a > future modular portage, tgz, deb, rpm, etc. creation could be performed > by modules. Until that time, I think it should happen externally. Converting introduces its own problems. You would have to elaborate on this statement- it's a bit vague at the moment what conversion of alternate formats to the binpkg format would gain. Regarding creation of rpm's, portage has had that support for a while now (it was duct taped into ebuild.sh). > > No? Then where would a tool to manipulate _package_ databases belong? > > In a slackware specific wrapper package that wraps around portage such > that it gets more slack compatibility. Such a package would also ensure > that the core packages do not come from the gentoo tree, but from > slackware. It's been stated elsewhere, but to restate it again... portage != gentoo . Portage *should* not impose any type of restriction as to which tree 'core' packages come from. It's not even particularly feasible to attempt it if you're aware of the internals. The slack 'compatibility' part is addressed below. > ps. I myself consider running hybrid distributions dangerous. Don't then, frankly. That doesn't mean a potential direction for portage development should be avoided. It's potentially dangerous mixing binpkgs in a system that's strictly src, yet users do it. Portage is a tool, tiz up to the user if they want to shoot themselves in the foot (another unix principle). Back to the 'make it a wrapper' thing, for it to be external, that's not in line with the current goals of most of the portage developers- see genone's omecron design spec, and jstubbs compilation of portage goals. Additionally, it will be a pain in the ass forcing the wrapper to basically duplicate dependency resolution, eg, pulling from it's tree/repository when possible, falling back to querying portage. If it's going to be implemented, it should be implemented _in_ portage as a specific tree type, with the format properly wrapped/abstracted. Portage currently isn't incredibly far along in internally wrapping the ebuild format into it's own class, but it is intended. ~brian -- gentoo-portage-dev@gentoo.org mailing list