| 1 |
Grobian wrote: |
| 2 |
> Please find attached GLEP 47: "Creating 'safe' environment variables". |
| 3 |
> |
| 4 |
> The GLEP is a Gentoo/Alt initiative. Constructive comments are welcome. |
| 5 |
> |
| 6 |
|
| 7 |
> |
| 8 |
> The variables ``ELIBC``, ``KERNEL`` and ``ARCH`` are currently set in |
| 9 |
> the profiles when other than their defaults for a GNU/Linux system. |
| 10 |
> They can as such easily be overridden and defined by the user. To |
| 11 |
> prevent this from happening, the variables should be auto filled by |
| 12 |
> Portage itself, based on the ``CHOST`` variable. |
| 13 |
> |
| 14 |
> A map file can be used to have the various ``CHOST`` values being |
| 15 |
> translated to the correct values for the four variables. This change is |
| 16 |
> invisible for ebuilds and eclasses, but allows to rely on these |
| 17 |
> variables as they are based on a 'safe' value -- the ``CHOST`` variable. |
| 18 |
|
| 19 |
Assuming the CHOST variable is 'safe' is not a good thing, users can |
| 20 |
over-ride this variable. Can you specify some behavior when it's set to |
| 21 |
something bogus ( invalid form ) or something thats not in the mapping? |
| 22 |
|
| 23 |
> Ebuilds should not be sensitive to the keyword value, but use the |
| 24 |
> aforementioned four variables instead. They allow specific tests for |
| 25 |
> properties. If this is undesirable, the full ``CHOST`` variable can be |
| 26 |
> used to match a complete operating system. |
Archives