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 1FgMx9-0000Hz-Mv for garchives@archives.gentoo.org; Wed, 17 May 2006 14:24:44 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4HEM1hi004343; Wed, 17 May 2006 14:22:01 GMT Received: from smtp-out4.blueyonder.co.uk (smtp-out4.blueyonder.co.uk [195.188.213.7]) by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4HECgGL015928 for ; Wed, 17 May 2006 14:12:42 GMT Received: from [172.23.170.143] (helo=anti-virus02-10) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1FgMlW-0007bo-Qq for gentoo-dev@lists.gentoo.org; Wed, 17 May 2006 15:12:42 +0100 Received: from [213.121.151.206] (helo=snowdrop.home) by asmtp-out1.blueyonder.co.uk with esmtpa (Exim 4.52) id 1FgMlW-0000av-5A for gentoo-dev@lists.gentoo.org; Wed, 17 May 2006 15:12:42 +0100 Date: Wed, 17 May 2006 15:12:20 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Paludis and Profiles Message-ID: <20060517151220.02ef3801@snowdrop.home> In-Reply-To: <20060516225638.GB29839@nightcrawler> References: <20060516161549.442b4d8a@localhost> <20060516161618.GB28745@nightcrawler> <20060516174742.66cf8f04@snowdrop.home> <20060516173356.GC28745@nightcrawler> <20060516190705.0f865431@snowdrop.home> <20060516195511.GA29839@nightcrawler> <20060516215017.7ed825ac@snowdrop.home> <20060516225638.GB29839@nightcrawler> X-Mailer: Sylpheed-Claws 2.1.1 (GTK+ 2.8.17; i686-pc-linux-gnu) 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 Content-Transfer-Encoding: 7bit X-Archives-Salt: d920fe5f-7166-4475-a119-63c55f5427f8 X-Archives-Hash: fba77893f56e0ac1f7cebd0c567929d3 On Tue, 16 May 2006 15:56:38 -0700 Brian Harring wrote: | This whole thing seems a bit dumb; it's not that far off from someone | coming along with a non-compliant c compiler, and arguing that | they're still compliant, they just dropped the stupid stuff they | didn't like. And this is why your whole argument is nonsensical. C is a documented and fixed standard (or rather, several of them). | > | Add binpkgs, and try it- you'll get some fun behaviour there. | > | > As we're not emulating Portage's binary package format, it's not an | > issue at all. | | Doesn't matter *how* you bundle the ebuild data (cpio/tar/whatever), | the issue of reloading the env still will exist, the container for | the data doesn't matter. What's your point? | > A lot of the ebuild handling (especially environment) is done in | > C++. You're missing all kinds of things by only looking at the bash | > code. | | And portage does a lot of crazy shit in python for env handling | also. Sooner or later however, it hands control over to bash with a | pregenerated environment for the ebuild to execute in- what I keep | pointing out (and you keep dodging) is that the ebuild env *must* be | consistant, regardless of the actual pkg manager implementation. And hey, we do provide a consistent environment. | You deviate from the standard of the tree, you break your support | for the tree. Pretty simple, users being the ones who see the mess. Ok, so the *tree* is the standard now, not Portage? That's good, because the tree is the standard we're using. | > | Feel free to suggest them- since it's initial discussion, your | > | comments on it haven't really progressed beyond "y'all did it | > | badly", without naming a solution that works. | > | > I gave you two that worked. One, the .ebuild.n thing, which avoids | > the filename incompatibility issue and the source issue. Two, the | > "eapi as a function" thing, which avoids the source issue. | | 1) sucks- folks aren't going to be happy when they have | mplayer-1.0.1.ebuild.25 Yes, but unfortunately it's the only way around Portage exploding horribly when it encounters something it doesn't understand. | 2) EAPI as a function is no different then EAPI as a var, just | massively slower since you have to shell out more. Untrue. If the eapi function checks that the eapi is supported and bails with an understandable error if not, the rest of the file doesn't have to be source compatible. | > Which is a good thing. Rather than emulating one of Portage's | > sillier misfeatures, which only came about because of the whole | > "single repository" concept being hard-coded, we did it properly. | | So... let me see if I grok this- last response, state it supports | eclass unified overlays (blurb above). Now you're stating that it | doesn't, because it's one of portage's misfeatures. Please don't | waste the bandwidth doing that again. Try defining your terms properly. It supports overlays with a unified eclass directory. It doesn't support overlays with unified eclasses from different directories. | Stating it "won't be a silent failure" does not make it so- line 1023 | of portage.py directly contradicts that. There are other ways of making Portage fail non-silently, as you know fine well. | If your parent parsing implementation handled N parents on a single | line (rather then parent per line as you do now), portage would | explode rather then silently use the left most. Your implementation | isn't doing that however... Disallows spaces in paths. Which, admittedly, is probably a good thing. | > | Bit retarded here, but seriously, work it out in the overlay | > | (like most herds do), then try to bring it to the tree. | > | > Oh, we already went through that stage. | | So... where's the sample profile? :) Elsewhere in the thread. | > | That and the thread is getting fairly wide in discusion, rather | > | then the profile specific "does alt pkg manager X cruft belong in | > | the tree?" | > | > Well yes, because rather than discussing the issues, you're trying | > to turn this into your personal crusade against Paludis. | | Sorry you see it that way, meanwhile kindly address the points I've | been raising What points? When you start coming up with points relevant to a Paludis profile and stop using this as a personal vendetta I might be interested. -- Ciaran McCreesh Mail : ciaran dot mccreesh at blueyonder.co.uk -- gentoo-dev@gentoo.org mailing list