public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Alexis Ballier <aballier@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] FEATURES use or misuse?
Date: Tue, 3 Nov 2009 22:26:24 +0100	[thread overview]
Message-ID: <20091103222624.112091f5@gentoo.org> (raw)
In-Reply-To: <200911031648.04090.patrick@gentoo.org>

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

> To quote:
> "FEATURES is a portage specific package manager configuration
> variable not specified in PMS and cannot reliably be used in ebuilds
> or eclasses."

For distcc & ccache, let me quote ebuild.sh code:

if hasq distcc $FEATURES ; then
	export PATH="/usr/lib/distcc/bin:$PATH"
        [[ -n $DISTCC_LOG ]] && addwrite "${DISTCC_LOG%/*}"
fi

if hasq ccache $FEATURES ; then
	export PATH="/usr/lib/ccache/bin:$PATH"
[...]

Do you want an example how to mimic this with portage without having
neither distcc nor ccache in FEATURES?
Even with portage, checking the FEATURES variable isn't reliable. If
you do not want to fix the real bugs and check/disable distcc/ccache
for any reason, then check PATH.

If you want to keep this simple, write an eclass providing functions
for disabling/checking these features.

> Well then, I suggest we finally start documenting reality and fix
> PMS. The use of the FEATURES variable, while it has been there
> for ... uhm ... as long as I can think back, actually :), should not
> be randomly suppressed. 

If you want to fix PMS, then send a patch rephrasing it to explain why
it isn't correct to check FEATURES in some cases. On the other hand, as
its name implies, PMS is a spec, not a documentation on why every
single choice has been made.

> So ... what's your opinion? Should we do things as they are correct,
> or as they are specified in PMS?

PMS may have some flaws, but not these, sorry.

> ( /me points at bash 3.0 )

Ever thought about backward compatibility and keeping a sane upgrade
path? Because that's exactly what this EAPI & PMS debate is all about
IMHO.


Regards,

Alexis.

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

  parent reply	other threads:[~2009-11-03 21:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-03 15:48 [gentoo-dev] FEATURES use or misuse? Patrick Lauer
2009-11-03 17:27 ` Sebastian Pipping
2009-11-03 20:36   ` Patrick Lauer
2009-11-03 20:58     ` Ciaran McCreesh
2009-11-03 22:28       ` Patrick Lauer
2009-11-04  0:11         ` [gentoo-dev] " Ryan Hill
2009-11-04  8:26           ` Patrick Lauer
2009-11-05  1:36             ` Ryan Hill
2009-11-05  4:56               ` [gentoo-dev] a pragmatic approach to FEATURES [was FEATURES use or misuse?] Brian Harring
2009-11-05  8:49                 ` Thilo Bangert
2009-11-05  9:36                   ` Brian Harring
2009-11-08  9:21                     ` Thilo Bangert
2009-11-03 21:26 ` Alexis Ballier [this message]
2009-11-03 22:04   ` [gentoo-dev] FEATURES use or misuse? Patrick Lauer
2009-11-03 22:26     ` Ciaran McCreesh
2009-11-04  0:33     ` Sebastian Pipping
2009-11-04  8:26       ` Patrick Lauer
2009-11-03 23:04 ` David Leverton
2009-11-04  1:31   ` [gentoo-dev] " Duncan
2009-11-04 22:12 ` Peter Hjalmarsson
2009-11-05  5:04   ` Brian Harring

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=20091103222624.112091f5@gentoo.org \
    --to=aballier@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