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 1NBHLZ-0008VF-8Z for garchives@archives.gentoo.org; Fri, 20 Nov 2009 00:27:33 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1BEBAE1215; Fri, 20 Nov 2009 00:26:59 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D24F3E121E for ; Fri, 20 Nov 2009 00:26:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 8060567D4F for ; Fri, 20 Nov 2009 00:26:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.963 X-Spam-Level: X-Spam-Status: No, score=-1.963 required=5.5 tests=[AWL=0.636, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM1nhXIDSN0J for ; Fri, 20 Nov 2009 00:26:50 +0000 (UTC) Received: from mail-fx0-f211.google.com (mail-fx0-f211.google.com [209.85.220.211]) by smtp.gentoo.org (Postfix) with ESMTP id E35BE676AC for ; Fri, 20 Nov 2009 00:26:49 +0000 (UTC) Received: by fxm3 with SMTP id 3so3071169fxm.24 for ; Thu, 19 Nov 2009 16:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to :content-type:content-transfer-encoding; bh=SbjwVDpg1mPk6XqnsdFUYoNhWrQg4+d2oslN7gpyigY=; b=nE/bs5LNhnovpMP2Fx0ceOhsULmz03+vXgWuqdZzTM3H6cHCHmgNJHWovPGo7PqOus N/zBCxXIF2UN3o2SqKKOLMwQK2llRkIg0wAoRb1NMwpqj0NuBU9Hfv1f59BpyTRLA8ml lK5zYCgT8Bv8RlMOwLzVIdvbW0t0ypwtCRifM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=QkyOV+vsd3NTULJNV9xS05cUjonb9ntyBRSfPJJjcXNAHi/6ZWgFQxQKXt5vgILP6G 1FCeiJcnh3v6z1oyAT+nAFFHUkFiZ060Q1GNXwp7uPfSlH6r0QVgK/wJEiuYshlo4qfN jN+G8bjl3ETr9KosH7QxjsFhmQduNrjcJ/b8M= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Sender: denis.dupeyron@gmail.com Received: by 10.216.90.9 with SMTP id d9mr204867wef.201.1258676808565; Thu, 19 Nov 2009 16:26:48 -0800 (PST) In-Reply-To: <20091018091154.GB464@gentoo.org> References: <20091018091154.GB464@gentoo.org> Date: Thu, 19 Nov 2009 17:26:48 -0700 X-Google-Sender-Auth: 04585b51012fc94f Message-ID: <7c612fc60911191626p7c32374fhf597787f2d30dfd3@mail.gmail.com> Subject: Re: [gentoo-dev] Gentoo Prefix: on EPREFIX, ED and EROOT inside ebuilds From: Denis Dupeyron To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 2cdb1c0f-2b63-4583-96fd-d6dc2424973e X-Archives-Hash: 873215f55ff76ac97e9e57f5b1665649 On Sun, Oct 18, 2009 at 2:11 AM, Fabian Groffen wrote: > This is a formal apology for springing that onto you. Thanks a lot. Not everybody can do such a thing as a public apology. I will nonetheless ask the council to vote on the following during next meeting: Ask Fabian to change his signature from: "Gentoo on a different level" To: "Failure in a different level" ;o) 2009/10/18 Tom=C3=A1=C5=A1 Chv=C3=A1tal : > Why on earth portage simply does not detect the prefix enviroment is bein= g run > and then INTERNALY switch D->ED and other variables. If that means we can get away without touching ebuilds, apart from changing their EAPI variable, then that's absolutely what we have to do. I'd like things to be done the right way though (see below). On Fri, Nov 13, 2009 at 4:43 AM, Ulrich Mueller wrote: > However, there is need for additional discussion. From the council > meeting log I could extract the following open questions: It would be preferable for the discussion to happen on this list before the meeting or we'll end up postponing again due to having more questions coming up at that time. > 2. Should the Prefix team be allowed to do the necessary changes to > ebuilds themselves, or should it be done by the respective > maintainers? I think here it's obvious that anybody who is an ebuild dev and sees anything to fix (prefix or else) is encouraged to go ahead and do it, as we've always done. The recommendation is and will always be to talk to the current maintainers out of politeness and to be extra careful (i.e. usually letting the maintainers do it) in case of system/tricky/exotic package. We don't give full cvs access to the whole tree to all ebuild devs for nothing. > 4. EAPI numbering: Would this simply be added as an additional > feature to EAPI 3? Or should we have an intermediate EAPI slot, > e.g. 2.1 or 3 (and current EAPI 3 renamed to 4 in the latter > case)? Here I'd add to the choices: why not release an intermediate EAPI with the prefix stuff and whatever that has already been done for EAPI3? The exact name of a potential intermediate EAPI is a non-problem. However I would prefer if it were a number like 2.1 or 2.5 or even 3, because although we currently treat the EAPI variable as a simple string we may change our mind later and find it handy someday to use operators on them such as >=3D2.1. > 5. Who is going to write the exact specification (PMS patch) for > this EAPI feature? I thought I asked Fabian to work on that at the end of the meeting. In case I didn't then consider this as me officially asking him if he can take care of it. Fabian is this OK with you? Also I think it would be nice if somebody took care of a portage patch, since I hear it is rather simple. Fabian again? Or Zac? Any other volunteers? I would prefer to have all the pieces in places before the next meeting so that we can vote on the real thing and have prefix implemented the right way before the end of the year. > 6. (Any question that I've missed?) Here are a few that I gathered from others (my comments are between parentheses): > How are dynamically linked set*id programs going to work? > How are scripts using #!shebangs going to work? > You write an ebuild, and you DEPEND upon >=3Dfoo-3, because the build > process includes some foo code. The foo code is executed via > scripts using #!/usr/bin/foo. Normally, this is fine. > But on prefix, /usr/bin/foo might be a crappy, OS X mangled foo-2 > that's no good. So even though you've got the foo-3 dep met, it'll be > met in /opt/Gentoo/blah, so your package will fail. > How are ebuilds to be marked as supporting prefix or not? (Here I'm guessing that changing the EAPI variable will do) > Why is there only a single permitted installation path? (I'm under the impression this is a limitation of the windows installer but not of prefix itself. So patching the installer would fix that) > What exactly is expected from a prefix-compliant package manager to > support full prefix installs, as opposed to just supporting installs > to / with prefix-aware ebuilds? (The PMS patch should answer that) Denis.