From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 68D2D13877A for ; Sat, 5 Jul 2014 11:13:43 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8BF0CE083E; Sat, 5 Jul 2014 11:13:41 +0000 (UTC) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id E4A94E081D for ; Sat, 5 Jul 2014 11:13:40 +0000 (UTC) Received: by mail-ve0-f174.google.com with SMTP id jx11so2401740veb.19 for ; Sat, 05 Jul 2014 04:13:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=ZQC5xjVjBCk59C3qq6bUe2TVQ5WdsVUvhK4AwmrtIok=; b=D1/6sR1sphWbRTx9Aktp0gCrd8M6p6j5E1r5xQUtmd20vdbx4M5aGEQoUG3sdvxH+S LQJxjaj9UN9s0N8EnklxPaghf2QRcXfqCp2nVgCR6e3xW4hmVBw9y36gTP15VWUMRdVm b0Hgcil1zvkuLOlNpFR+sh+b/9BZV8f5BR43XIimZYe4/9e3kpbOQo1IZpN+KLxlSRjK hbDlyKwd9QWrp4+6wg8PZrLpbXGzPmQJFbjQZJHJ/6WZNJhH2x64vNAM1u1STLJYVxGo x+YXgfHfgd3Vgu55QJZoY6NViaQq/TtLEI4Hjf5WpLH+zQ+o+YMxM6F03ZaIQAaNuB0T Ru2w== X-Gm-Message-State: ALoCoQkCjZhYxRwRHMiQQ+j3KBGVlXmPL/EUDAbprrLkH4q6mx+NMIp9mGKsZS7UaDcc4wLxdKW+ Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.220.166.9 with SMTP id k9mr14695061vcy.20.1404558819502; Sat, 05 Jul 2014 04:13:39 -0700 (PDT) Sender: gmt@be-evil.net Received: by 10.220.141.207 with HTTP; Sat, 5 Jul 2014 04:13:39 -0700 (PDT) X-Originating-IP: [75.147.143.254] In-Reply-To: References: Date: Sat, 5 Jul 2014 04:13:39 -0700 X-Google-Sender-Auth: uWzcpeS8riXE4d8FXpSVlMwktrw Message-ID: Subject: Re: [gentoo-portage-dev] Proposal of "uncooperative-root" in SUPPORTED_FEATURES From: Greg Turner To: gentoo-portage-dev@lists.gentoo.org Content-Type: multipart/alternative; boundary=047d7b3a8ae680f40604fd7055d2 X-Archives-Salt: 20c335b9-9503-4f5d-87d8-ea4433ae9631 X-Archives-Hash: f3a5f8868f460ef6a88739d67b756d3d --047d7b3a8ae680f40604fd7055d2 Content-Type: text/plain; charset=UTF-8 For a while my cygwin port needed something like this. The problem was, as, no doubt, the gentleman with the ridiculous name is all too familiar, that you are fighting against a very long-standing convention. Anything based on autotools tends to be a serious disaster, for example. There was another problem -- more of an institutional/human-nature thing than a technical problem. When I was on this same mission as you, silly-name, it quickly became clear that people didn't give a shit and didn't want those patches. I hope those of you who I'm referring to won't be offended by that -- I'm not making a normative statement here, just what I believe to be a factual one. Indeed there were many good reasons for them to feel that way, including: 1. They (the people who didn't give a shit) didn't share my problem or understand why I should have it. The explanation, in my case, was nontrivial. 2. The result of my approach was to greatly enlarge many core-system ebuilds with huge patches to the upstream code; those evaluating those patches would have been (I don't think I ever actually submitted them) the same whose responsibility it would have become to maintain them. In other words, my patches would have amounted to a request to sign the decision-maker up for a bunch of ongoing busy-work, which they had no personal stake in. 3. The number of people needing this feature would most likely have been very small (of course, arguably, that number could have grown, once the thing started to get off the ground. But that still left me with a chicken-and-egg problem even if it solved the justification problem). 4. It made alot of "tidy" ebuilds into "untidy" ebuilds. This creates a very real aesthetic problem and disinclines people to look on the proposition favorably, myself included. Humans like their technology to look pretty. I eventually found other ways to deal with it, and was able to drop those patches from my tree. But I lost many days of work screwing around with it. I guess my only advice to you is, I strongly suggest you find ways to solve this problem abstractly, rather than at an ebuild level, wherever possible. One way you might look at is LD_PRELOAD trickery, allowing you to simply lie about /bin/{ba,}sh and some other files' contents. That probably wouldn't have worked in my case, but I suspect it might in yours. If that won't work, then I guess my next idea would be to maintain a library of code-injection hacks that could automatically fix those out-of-prefix references in scripts and C code. Abstract approaches at least stand a chance by avoiding problems #2 and #4, which, I suspect, would be the big ones if you ever intend to upstream this feature. As for the idea of maintaining a huge overlay... sure, go for it, but be warned: it's really hard. -gmt On Sat, Jul 5, 2014 at 1:24 AM, X dej < dreplaceelettereejbyeletterea@gmail.com> wrote: > Hello to all, > > Summary: I have made many mods to sys-app/portage (2013 version). The > result is > a proposal of patch for latest sys-app/portage, see below. > > Main result of my mods to gentoo prefix: > > FEATURES=uncooperative-root emerge -bv =firefox-17 > > now works on EPREFIX on Android-4.1 ARM. I use neither fakeroot nor > GNURoot. > root access never required. Distributed as a .tbz2 and a .ebuild by > gentooandroid.sf.net, along with the necessary stage3. > > @dol-sen advised me one week ago on #gentoo-portage to post a rebased > patch for > HEAD of git.overlays.gentoo.org/proj/portage.git : I just hosted this > patch on > > sf.net/projects/gentooandroid/files/sys-app_portage-current-HEAD_patch/download > and it is also attached to this post, and to previous post on gentoo-dev > mailing list; Joshua Kinard from there just advised me to post this patch > at > gentoo-portage-dev (here). > > I request comments and discussions about this patch. Summary: > > pym/portage/const.py + (this is SUPPORTED_FEATURES+=uncooperative-root) > cnf/make.conf.example ++++++++++++++++++++++++++ > bin/ebuild-helpers/emake ++++++++ > bin/ebuild.sh --+++++++ > bin/misc-functions.sh -+++++ > bin/phase-helpers.sh +++++ > > My aim is to take your remarks into account, then to build an overlay > (will be > hosted at endrood.sf.net) with up-to-date versions of all my mods. The > final > result will be a tested version of above patch, together with lastest > builds > for firefox, squeak, scala, gnucash, ... > > Thanks for you attention. > > Xdej (I disclosed my real identity to Rick "Zero_Chaos" Farina). > --047d7b3a8ae680f40604fd7055d2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For a while my cygwin port needed something like this. =C2= =A0The problem was, as, no doubt, the gentleman with the ridiculous name is= all too familiar, that you are fighting against a very long-standing conve= ntion. =C2=A0Anything based on autotools tends to be a serious disaster, fo= r example.

There was another problem -- more of an institutional/human-= nature thing than a technical problem. =C2=A0When I was on this same missio= n as you, silly-name, it quickly became clear that people didn't give a= shit and didn't want those patches.

I hope those of you who I'm referring to won't = be offended by that -- I'm not making a normative statement here, just = what I believe to be a factual one. =C2=A0Indeed there were many good reaso= ns for them to feel that way, including:

1. They (the people who didn't give a shit) didn= 9;t share my problem or understand why I should have it. =C2=A0The explanat= ion, in my case, was nontrivial.

2. The result of = my approach was to greatly enlarge many core-system ebuilds with huge patch= es to the upstream code; those evaluating those patches would have been (I = don't think I ever actually submitted them) the same whose responsibili= ty it would have become to maintain them.

In other words, my patches would have amounted to a req= uest to sign the decision-maker up for a bunch of ongoing busy-work, which = they had no personal stake in.

3. The number of pe= ople needing this feature would most likely have been very small (of course= , arguably, that number could have grown, once the thing started to get off= the ground. =C2=A0But that still left me with a chicken-and-egg problem ev= en if it solved the justification problem).

4. It made alot of "tidy" ebuilds into "= untidy" ebuilds. =C2=A0This creates a very real aesthetic problem and = disinclines people to look on the proposition favorably, myself included. = =C2=A0Humans like their technology to look pretty.

I eventually found other ways to deal with it, and was = able to drop those patches from my tree. =C2=A0But I lost many days of work= screwing around with it.

I guess my only advice t= o you is, I strongly suggest you find ways to solve this problem abstractly= , rather than at an ebuild level, wherever possible.

One way you might look at is LD_PRELOAD trickery, allow= ing you to simply lie about /bin/{ba,}sh and some other files' contents= . =C2=A0That probably wouldn't have worked in my case, but I suspect it= might in yours. =C2=A0If that won't work, then I guess my next idea wo= uld be to maintain a library of code-injection hacks that could automatical= ly fix those out-of-prefix references in scripts and C code.

Abstract approaches at least stand a chance by avoiding= problems #2 and #4, which, I suspect, would be the big ones if you ever in= tend to upstream this feature. =C2=A0As for the idea of maintaining a huge = overlay... sure, go for it, but be warned: it's really hard.

-gmt
On Sat, Jul 5, 2014 at 1:24 AM, X dej <dreplaceelettereejbyeletterea@gmail.com> wrote= :
Hello to all,

Summary: I have made many mods to sys-app/portage (2013 version). The resul= t is
a proposal of patch for latest sys-app/portage, see below.

Main result of my mods to gentoo prefix:

=C2=A0 FEATURES=3Duncooperative-root emerge -bv =3Dfirefox-17

now works on EPREFIX on Android-4.1 ARM. I use neither fakeroot nor GNURoot= .
root access never required. Distributed as a .tbz2 and a .ebuild by gentooandroid.sf.= net, along with the necessary stage3.

@dol-sen advised me one week ago on #gentoo-portage to post a rebased patch= for
HEAD of git.overlays.gentoo.org/proj/portage.git : I= just hosted this patch on
sf.net/projects/gentooandroid/fil= es/sys-app_portage-current-HEAD_patch/download
and it is also attached to this post, and to previous post on gentoo-= dev
mailing list; Joshua Kinard from there just advised me to post this patch a= t
gentoo-portage-dev (here).

I request comments and discussions about this patch. Summary:

pym/portage/const.py =C2=A0 =C2=A0 + (this is SUPPORTED_FEATURES+=3Duncoope= rative-root)
cnf/make.conf.example =C2=A0 =C2=A0++++++++++++++++++++++++++
bin/ebuild-helpers/emake ++++++++
bin/ebuild.sh =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0--+++++++
bin/misc-functions.sh =C2=A0 =C2=A0-+++++
bin/phase-helpers.sh =C2=A0 =C2=A0 +++++

My aim is to take your remarks into account, then to build an overlay (will= be
hosted at endrood.sf.ne= t) with up-to-date versions of all my mods. The final
result will be a tested version of above patch, together with lastest build= s
for firefox, squeak, scala, gnucash, ...

Thanks for you attention.

Xdej (I disclosed my real identity to Rick "Zero_Chaos" Far= ina).

--047d7b3a8ae680f40604fd7055d2--