From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-doc@lists.gentoo.org
Subject: [gentoo-doc] Re: Portage per-package environment/behavior
Date: Wed, 28 Dec 2011 17:47:18 +0000 (UTC) [thread overview]
Message-ID: <pan.2011.12.28.17.47.17@cox.net> (raw)
In-Reply-To: 20111228101449.GA912@siphos.be
Sven Vermeulen posted on Wed, 28 Dec 2011 11:14:49 +0100 as excerpted:
> I noticed we don't describe in the handbook that Portage can have
> per-package environment variables (like CFLAGS) through
> /etc/portage/env.
IIRC this (and /etc/portage/patches) was originally deliberately kept an
"undocumented feature", to avoid trouble with missing info in bug
reports, since emerge info didn't report package specific information.
Now that portage has emerge --info <pkg> and it's what's requested in the
usual output when a build aborts (tho AFAIK bugzilla still mentions
emerge info output only), and the logs themselves are rather better at
reporting user patches (for the patches subdir), that's not so much of a
problem, and the portage documentation itself mentions both usages of the
env subdir (tho not the patches subdir since that's still ebuild
activated).
But the handbooks were rather stale before you came back and started the
update push (thanks again =:^), and this is the first time I believe I've
seen the issue raised.
I like the idea and believe it best fits in working with portage. The
new "advanced features" section you proposed sounds good.
Now that ccache has been deemphasized, perhaps move it there as well,
getting it a bit further out of the the newbie path. (Tho I personally
use it and have never had an issue... and don't necessarily agree with
the deemphasis since it really helps speed up rebuilds in the case where
users are likely to be most frustrated, a broken build that's later
fixed, or that aborted due to random job-token issues that aren't
repeatable, etc. But I understand why it's being done, from the gentoo-
dev perspective.)
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2011-12-28 17:48 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-28 10:14 [gentoo-doc] Portage per-package environment/behavior Sven Vermeulen
2011-12-28 17:20 ` wireless
2011-12-28 17:47 ` Duncan [this message]
2011-12-28 19:10 ` [gentoo-doc] " Sven Vermeulen
2011-12-28 18:01 ` [gentoo-doc] " Matthew Summers
2011-12-29 18:18 ` Sven Vermeulen
2011-12-30 1:56 ` [gentoo-doc] " Duncan
2011-12-30 12:29 ` Sven Vermeulen
2011-12-31 20:16 ` [gentoo-doc] " Sven Vermeulen
2011-12-31 23:41 ` [gentoo-doc] " Duncan
2012-01-01 3:13 ` [gentoo-doc] " Joshua Saddler
2012-01-01 8:59 ` Sven Vermeulen
2012-01-02 18:54 ` Joshua Saddler
2012-01-03 17:33 ` Sven Vermeulen
2012-01-01 9:30 ` [gentoo-doc] " Duncan
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=pan.2011.12.28.17.47.17@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-doc@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