public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Michael Haubenwallner <haubi@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev]  Re: [RFC] New keywords for non-Gentoo Linux platforms
Date: Tue, 14 Oct 2008 09:48:27 +0200	[thread overview]
Message-ID: <1223970507.18595.7.camel@sapc154.salomon.at> (raw)
In-Reply-To: <20081013175919.GB9586@gentoo.org>


On Mon, 2008-10-13 at 19:59 +0200, Fabian Groffen wrote:
> On 13-10-2008 15:27:10 +0100, Ciaran McCreesh wrote:
> > On Mon, 13 Oct 2008 06:16:01 +0100
> > Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> > > Unless someone can say what using PROPERTIES=prefix would break, I'd
> > > go with that. It's a /classic/ usage of that variable, as it's simply
> > > a boolean; PROPERTIES is well-defined and I'm hoping all the manglers
> > > support it. It'd be great to see the prefix branch finally merged so
> > > we all get to play with it.
> > 
> > It would break. Prefix ebuilds won't work unless ED is set, and a non
> > PROPERTIES aware or non-prefix-property aware package manager won't set
> > ED. Unless prefix is reimplemented to require no package manager
> > changes for the install to / case, PROPERTIES is out.
> 
> Just to comment on this possibility; I see an option, given the
> definition of ED and EROOT to do Prefix without them, by e.g. using
> ${D}${EPREFIX} instead of ${ED} as shorthand.  When ${EPREFIX} would be
> unset, this would result in simple ${D}, which is "backwards
> compatible".  This is not all what is necessary, but a big deal of it.
> 
> Question here, however, is whether this is worth it.  Personally, I
> prefer the shorthands, as they give a lot of readability.

Could it also work to initialize them in profile.bashrc if they are
unset?

Something like
        : ${EPREFIX=}
        : ${ED=${D}}
        : ${EROOT=${ROOT}}

/haubi/
-- 
Michael Haubenwallner
Gentoo on a different level




  reply	other threads:[~2008-10-14  7:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-09 18:11 [gentoo-dev] [RFC] New keywords for non-Gentoo Linux platforms Fabian Groffen
2008-10-09 22:05 ` Marius Mauch
2008-10-10  0:16   ` [gentoo-dev] " Duncan
2008-10-10  2:21     ` Marius Mauch
2008-10-10  7:15       ` Fabian Groffen
2008-10-10 12:40         ` Diego 'Flameeyes' Pettenò
2008-10-10 12:48           ` Fabian Groffen
2008-10-10 15:56             ` Marius Mauch
2008-10-10 16:13               ` Robert Bridge
2008-10-10 15:21         ` Ryan Hill
2008-10-10  8:56 ` [gentoo-dev] " Michael Haubenwallner
2008-10-10 12:56 ` Jeremy Olexa
2008-10-13  5:16   ` [gentoo-dev] " Steve Long
2008-10-13 14:27     ` Ciaran McCreesh
2008-10-13 17:59       ` Fabian Groffen
2008-10-14  7:48         ` Michael Haubenwallner [this message]
2008-10-15 10:20           ` [gentoo-dev] " Steve Long
2008-10-17 14:22 ` [gentoo-dev] " Michael Haubenwallner
2008-10-21 14:09   ` [gentoo-dev] " Tiziano Müller
2008-10-21 19:01     ` Fabian Groffen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1223970507.18595.7.camel@sapc154.salomon.at \
    --to=haubi@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox