public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Ciaran McCreesh <ciaran.mccreesh@googlemail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [RFC] Adding features to Portage that work on top of any EAPI
Date: Fri, 10 Oct 2008 17:10:20 +0100	[thread overview]
Message-ID: <20081010171020.28b4caa5@snowmobile> (raw)
In-Reply-To: <90b936c0810100840q4d1793bei18477a6e85815e32@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

On Fri, 10 Oct 2008 10:40:53 -0500
"Jeremy Olexa" <darkside@gentoo.org> wrote:
> In a way I feel like we (the Prefix project) are mis-using the EAPI
> value.

You're misusing it in the way you treat it as a set of strings rather
than a single value. But this being an EAPI thing seems right.

> If we have something that is designed to work with *any* EAPI,
> is it really a special EAPI? haubi said something on the gentoo-alt
> list that made me think about this more:
> "When an usecase of something is orthogonal to what that thing is
> designed for, one should consider using a different thing for this
> usecase." -source unknown
> 
> Is this PROPERTIES-like information? Is that easily supportable in
> the PM?

I don't see it as orthogonal.

Here's the thing: you can't use prefix ebuilds in a non-prefix-aware
package manager because things like ED will be unset. If prefix ebuilds
could work (as in, install unprefixed) in a purely vanilla package
manager with no prefix awareness, it could be done using PROPERTIES or
some similar variable. But prefix won't work at all unless its
extensions are present, and it also appears to require changes to
things that are defined differently in different EAPIs.

I suspect most of the problem is down to timescale. The prefix
development time is spread out over three EAPIs so far, so you need
three sets of (mostly similar) extensions. Had prefix taken less time
to be worked out, it'd fairly clearly be something that could just go
straight in to the next EAPI, with duplicated base system packages in
an overlay to avoid having to use new EAPIs for core things in the
main tree.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

      reply	other threads:[~2008-10-10 16:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-09 17:46 [gentoo-dev] [RFC] Adding features to Portage that work on top of any EAPI Fabian Groffen
2008-10-09 18:15 ` Ciaran McCreesh
2008-10-09 18:54   ` Fabian Groffen
2008-10-10 15:40   ` Jeremy Olexa
2008-10-10 16:10     ` Ciaran McCreesh [this message]

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=20081010171020.28b4caa5@snowmobile \
    --to=ciaran.mccreesh@googlemail.com \
    --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