From: wireless <wireless@tampabay.rr.com>
To: gentoo-doc@lists.gentoo.org
Subject: Re: [gentoo-doc] Portage per-package environment/behavior
Date: Wed, 28 Dec 2011 12:20:17 -0500 [thread overview]
Message-ID: <4EFB4FD1.30204@tampabay.rr.com> (raw)
In-Reply-To: <20111228101449.GA912@siphos.be>
On 12/28/11 05:14, Sven Vermeulen wrote:
> Hi guys,
>
> I noticed we don't describe in the handbook that Portage can have
> per-package environment variables (like CFLAGS) through /etc/portage/env.
> This can be even (ab?)used to execute steps before or after specific phases
> (based on the EBUILD_PHASE information), something I use for updating IDS
> systems (postinst/prerm phase).
>
> But I'm not sure if and where in the handbook this can be positioned best.
> The environment variable stuff could be placed in the section on
> "Environment Variables", but is quite off from the rest of the content
> (since the rest of that chapter has nothing really to do with Portage or
> build environments).
>
> "Configuring through Variables" is probably the best location (somewhere in
> the beginning as we talk there about Build-specific Options), but I do feel
> that this particular feature is already more targeting advanced users, where
> the location in the handbook somewhat suggests this for more beginner-like
> types.
>
> Perhaps another section in "Working with Portage", called "Advanced Portage
> Features" or so? This can then contain the per-package env information, but
> also overriding profile information and perhaps others we don't talk about
> yet.
>
> Any ideas on this?
>
> Sven
Well, imho, a handbook installation is about basics and during the
initial build, particularly for one new to gentoo, extensive
flag settings (customization via /etc/portage) might cause more
problems than any gains might achieve. Remember we do that the
various profiles for the different desktop and server configs.
What would be nice is to created stripped down versions of the handbook
(on the WIKI) where the focus is more highly specialized configuration
for the use of the newly installed (gentoo) machine. Also on the gentoo
wiki, we can lower the bar, and let those accomplished individuals
create something cool, and a developing admin take it over and
maintain the document, or extend it to different hardware platforms.
Flag customization could easily differ on different platforms.
Why, one could even use embedded gentoo with uClib as a basis
for a targeted, customized build of Gentoo on the new installation
(hardware).
(side note, if AMD follows through and starts offering
ARM (A15) machines, our current handbook will be ripped
at the seams, imho.
Some examples for the WIKI:
An Apache server:
complete with either hardened or SElinux setup,
including packages such as perl, python, php (or whatever mix).
There, your customized flag settings would be focused and very
keenly appreciated for an intermediate level gentoo admin to
leverage.
Some other intermediate level ideas for the WIKI:
Light-weight workstation:
with gui for older hardware (not Gnome or KDE)
secure/encrypted mail server
firewall (with DMZ for servers).
transparent bridge.
transparent sniffer:
with lots of ethernet interfaces set up in stealth mode
(taps to other secure ethernet segments for passive monitoring.
In these (and many others exist) customization as well as minimization
of flag settings would be of keen interest to the wider, intermediate
gentoo community. God forbid one of the really sharp (gentoo) hacks
share a little magic with us commoners?
So keep the handbook the same but start experimenting (via the WIKI)
on derivatives that are more targeted and focused on customizations,
including but not limited to stringent flag settings
Just my thoughts, YMMV.
James
next prev parent reply other threads:[~2011-12-28 17:20 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 [this message]
2011-12-28 17:47 ` [gentoo-doc] " Duncan
2011-12-28 19:10 ` 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=4EFB4FD1.30204@tampabay.rr.com \
--to=wireless@tampabay.rr.com \
--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