| 1 |
grobian |
1.1 |
GLEP: 47
|
| 2 |
|
|
Title: Creating 'safe' environment variables
|
| 3 |
|
|
Version: $Revision: 1.8 $
|
| 4 |
|
|
Last-Modified: $Date: 2006/01/26 20:56:55 $
|
| 5 |
|
|
Author: Diego Pettenò, Fabian Groffen <{flameeyes,grobian}@gentoo.org>
|
| 6 |
|
|
Status: Active
|
| 7 |
|
|
Type: Standards Track
|
| 8 |
|
|
Content-Type: text/x-rst
|
| 9 |
|
|
Created: 14-Oct-2005
|
| 10 |
|
|
Post-History:
|
| 11 |
|
|
|
| 12 |
|
|
|
| 13 |
|
|
Credits
|
| 14 |
|
|
=======
|
| 15 |
|
|
|
| 16 |
|
|
The text of this GLEP is a result of a discussion and input of the
|
| 17 |
|
|
following persons, in no particular order: Mike Frysinger, Diego
|
| 18 |
|
|
Pettenò, Fabian Groffen and Finn Thain.
|
| 19 |
|
|
|
| 20 |
|
|
|
| 21 |
|
|
Abstract
|
| 22 |
|
|
========
|
| 23 |
|
|
|
| 24 |
|
|
In order for ebuilds and eclasses to be able to make host specific
|
| 25 |
|
|
decisions, it is necessary to have a number of environmental variables
|
| 26 |
|
|
which allow for such decisions. This GLEP introduces some measures that
|
| 27 |
|
|
need to be made to make these decisions 'safe', by making sure the
|
| 28 |
|
|
variables the decisions are based on are 'safe'. A small overlap with
|
| 29 |
|
|
GLEP 22 [1]_ is being handled in this GLEP where the use of 2-tuple
|
| 30 |
|
|
keywords are being kept instead of 4-tuple keywords. Additionally, the
|
| 31 |
|
|
``ELIBC``, ``KERNEL`` and ``ARCH`` get auto filled starting from
|
| 32 |
|
|
``CHOST`` and the 2-tuple keyword, instead of solely from they 4-tuple
|
| 33 |
|
|
keyword as proposed in GLEP 22.
|
| 34 |
|
|
|
| 35 |
|
|
The destiny of the ``USERLAND`` variable is out of the scope of this
|
| 36 |
|
|
GLEP. Depending on its presence in the tree, it may be decided to set
|
| 37 |
|
|
this variable the same way we propose to set ``ELIBC``, ``KERNEL`` and
|
| 38 |
|
|
``ARCH``, or alternatively, e.g. via the profiles.
|
| 39 |
|
|
|
| 40 |
|
|
|
| 41 |
|
|
Motivation
|
| 42 |
|
|
==========
|
| 43 |
|
|
|
| 44 |
|
|
The Gentoo/Alt project is in an emerging state to get ready to serve a
|
| 45 |
|
|
plethora of 'alternative' configurations such as FreeBSD, NetBSD,
|
| 46 |
|
|
DragonflyBSD, GNU/kFreeBSD, Mac OS X, (Open)Darwin, (Open)Solaris and so
|
| 47 |
|
|
on. As such, the project is in need for a better grip on the actual
|
| 48 |
|
|
host being built on. This information on the host environment is
|
| 49 |
|
|
necessary to make proper (automated) decisions on settings that are
|
| 50 |
|
|
highly dependant on the build environment, such as platform or as in
|
| 51 |
|
|
[2]_.
|
| 52 |
|
|
|
| 53 |
|
|
|
| 54 |
|
|
Rationale
|
| 55 |
|
|
=========
|
| 56 |
|
|
|
| 57 |
|
|
Gentoo's unique Portage system allows easy installation of applications
|
| 58 |
|
|
from source packages. Compiling sources is prone to many environmental
|
| 59 |
|
|
settings and availability of certain tools. Only recently the Gentoo
|
| 60 |
|
|
for FreeBSD project has started, as second Gentoo project that operates
|
| 61 |
|
|
on a foreign host operating system using foreign (non-GNU) C-libraries
|
| 62 |
|
|
and userland utilities. Such projects suffer from the current implicit
|
| 63 |
|
|
assumption made within Gentoo Portage's ebuilds that there is a single
|
| 64 |
|
|
type of operating system, C-libraries and system utilities. In order to
|
| 65 |
|
|
enable ebuilds -- and also eclasses -- to be aware of these
|
| 66 |
|
|
environmental differences, information regarding it should be supplied.
|
| 67 |
|
|
Since decisions based on this information can be vital, it is of high
|
| 68 |
|
|
importance that this information can be trusted and the values can be
|
| 69 |
|
|
considered 'safe' and correct.
|
| 70 |
|
|
|
| 71 |
|
|
|
| 72 |
|
|
Backwards Compatibility
|
| 73 |
|
|
=======================
|
| 74 |
|
|
|
| 75 |
|
|
The proposed keywording scheme in this GLEP is fully compatible with the
|
| 76 |
|
|
current situation of the portage tree, this in contrast to GLEP 22. The
|
| 77 |
|
|
variables provided by GLEP 22 can't be extracted from the new keyword,
|
| 78 |
|
|
but since GLEP 22-style keywords aren't in the tree at the moment, that
|
| 79 |
|
|
is not a problem. The same information can be extracted from the CHOST
|
| 80 |
|
|
variable, if necessary. No modifications to ebuilds will have to be
|
| 81 |
|
|
made.
|
| 82 |
|
|
|
| 83 |
|
|
|
| 84 |
|
|
Specification
|
| 85 |
|
|
=============
|
| 86 |
|
|
|
| 87 |
|
|
Unlike GLEP 22 the current keyword scheme as used in practice is not
|
| 88 |
|
|
changed. Instead of proposing a 4-tuple [3]_ keyword, a 2-tuple
|
| 89 |
|
|
keyword is chosen for archs that require them. Archs for which a
|
| 90 |
|
|
1-tuple keyword suffices, keep that keyword. Since this doesn't change
|
| 91 |
|
|
anything to the current situation in the tree, it is considered to be a
|
| 92 |
|
|
big advantage over the 4-tuple keyword from GLEP 22. This GLEP is an
|
| 93 |
|
|
official specification of the syntax of the keyword.
|
| 94 |
|
|
|
| 95 |
|
|
Keywords will consist out of two parts separated by a hyphen ('-'). The
|
| 96 |
|
|
left hand part of the keyword 2-tuple is the architecture, such as
|
| 97 |
|
|
ppc64, sparc and x86. The right hand part indicates the operating
|
| 98 |
|
|
system or distribution, such as linux, macos, darwin, obsd, etc. If the
|
| 99 |
|
|
right hand part is omitted, it implies the operating system/distribution
|
| 100 |
|
|
type is GNU/Linux. In such case the hyphen is also omitted. Examples
|
| 101 |
|
|
of such keywords are ppc-darwin and x86. This is fully compatible with
|
| 102 |
|
|
the current keywords used in the tree.
|
| 103 |
|
|
|
| 104 |
|
|
The variables ``ELIBC``, ``KERNEL`` and ``ARCH`` are currently set in
|
| 105 |
|
|
the profiles when other than their defaults for a GNU/Linux system.
|
| 106 |
|
|
They can as such easily be overridden and defined by the user. To
|
| 107 |
|
|
prevent this from happening, the variables should be auto filled by
|
| 108 |
|
|
Portage itself, based on the ``CHOST`` variable.
|
| 109 |
|
|
|
| 110 |
|
|
A map file can be used to have the various ``CHOST`` values being
|
| 111 |
|
|
translated to the correct values for the four variables. This change is
|
| 112 |
|
|
invisible for ebuilds and eclasses, but allows to rely on these
|
| 113 |
|
|
variables as they are based on a 'safe' value -- the ``CHOST`` variable.
|
| 114 |
|
|
Ebuilds should not be sensitive to the keyword value, but use the
|
| 115 |
|
|
aforementioned four variables instead. They allow specific tests for
|
| 116 |
|
|
properties. If this is undesirable, the full ``CHOST`` variable can be
|
| 117 |
|
|
used to match a complete operating system.
|
| 118 |
|
|
|
| 119 |
|
|
Current USE-expansion is being maintained, for backwards compatibility.
|
| 120 |
|
|
Since the expansion is based on the variables mentioned above which do
|
| 121 |
|
|
not change, but only in the way they are generated, there should be no
|
| 122 |
|
|
problem in maintaining them.
|
| 123 |
|
|
|
| 124 |
|
|
|
| 125 |
|
|
Variables
|
| 126 |
|
|
---------
|
| 127 |
|
|
|
| 128 |
|
|
The ``ELIBC``, ``KERNEL``, ``ARCH`` variables are filled from a profile
|
| 129 |
|
|
file. The file can be overlaid, such that the following entries in the
|
| 130 |
|
|
map file (on the left of the arrow) will result in the assigned
|
| 131 |
|
|
variables on the right hand side of the arrow:
|
| 132 |
|
|
|
| 133 |
|
|
::
|
| 134 |
|
|
|
| 135 |
|
|
*-*-linux-* -> KERNEL="linux"
|
| 136 |
|
|
*-*-*-gnu -> ELIBC="glibc"
|
| 137 |
|
|
*-*-kfreebsd-gnu -> KERNEL="FreeBSD" ELIBC="glibc"
|
| 138 |
|
|
*-*-freebsd* -> KERNEL="FreeBSD" ELIBC="FreeBSD"
|
| 139 |
|
|
*-*-darwin* -> KERNEL="Darwin" ELIBC="Darwin"
|
| 140 |
|
|
*-*-netbsd* -> KERNEL="NetBSD" ELIBC="NetBSD"
|
| 141 |
|
|
*-*-solaris* -> KERNEL="Solaris" ELIBC="Solaris"
|
| 142 |
|
|
|
| 143 |
|
|
A way to achieve this is proposed by Mike Frysinger [4]_, which
|
| 144 |
|
|
suggests to have a env-map file, for instance filled with:
|
| 145 |
|
|
|
| 146 |
|
|
::
|
| 147 |
|
|
|
| 148 |
|
|
% cat env-map
|
| 149 |
|
|
*-linux-* KERNEL=linux
|
| 150 |
|
|
*-gnu ELIBC=glibc
|
| 151 |
|
|
x86_64-* ARCH=amd64
|
| 152 |
|
|
|
| 153 |
|
|
then the following bash script can be used to set the four variables to
|
| 154 |
|
|
their correct values:
|
| 155 |
|
|
|
| 156 |
|
|
::
|
| 157 |
|
|
|
| 158 |
|
|
% cat readmap
|
| 159 |
|
|
#!/bin/bash
|
| 160 |
|
|
|
| 161 |
|
|
CBUILD=${CBUILD:-${CHOST=${CHOST:-$1}}}
|
| 162 |
|
|
[[ -z ${CHOST} ]] && echo need chost
|
| 163 |
|
|
|
| 164 |
|
|
unset KERNEL ELIBC ARCH
|
| 165 |
|
|
|
| 166 |
|
|
while read LINE ; do
|
| 167 |
|
|
set -- ${LINE}
|
| 168 |
|
|
targ=$1
|
| 169 |
|
|
shift
|
| 170 |
|
|
[[ ${CBUILD} == ${targ} ]] && eval $@
|
| 171 |
|
|
done < env-map
|
| 172 |
|
|
|
| 173 |
|
|
echo ARCH=${ARCH} KERNEL=${KERNEL} ELIBC=${ELIBC}
|
| 174 |
|
|
|
| 175 |
|
|
Given the example env-map file, this script would result in:
|
| 176 |
|
|
|
| 177 |
|
|
::
|
| 178 |
|
|
|
| 179 |
|
|
% ./readmap x86_64-pc-linux-gnu
|
| 180 |
|
|
ARCH=amd64 KERNEL=linux ELIBC=glibc
|
| 181 |
|
|
|
| 182 |
|
|
It should be noted, however, that the bash script is a proof of concept
|
| 183 |
|
|
implementation. It cannot be used as Portage will need this
|
| 184 |
|
|
information, which is written in Python. Hence, an equivalent of this
|
| 185 |
|
|
bash script should be written in Python to be able to use it within
|
| 186 |
|
|
Portage. This is considered to be a non-issue coding wise.
|
| 187 |
|
|
|
| 188 |
|
|
|
| 189 |
|
|
References
|
| 190 |
|
|
==========
|
| 191 |
|
|
|
| 192 |
|
|
.. [1] GLEP 22, New "keyword" system to incorporate various
|
| 193 |
|
|
userlands/kernels/archs, Goodyear,
|
| 194 |
|
|
(http://glep.gentoo.org/glep-0022.html)
|
| 195 |
|
|
|
| 196 |
|
|
.. [2] For example in the perl ebuild, it is necessary to
|
| 197 |
|
|
fill in the C-library part, which on a FreeBSD system is other than
|
| 198 |
|
|
on a Linux system and currently is handled as follows:
|
| 199 |
|
|
::
|
| 200 |
|
|
|
| 201 |
|
|
[[ ${ELIBC} == "FreeBSD" ]] && myconf="${myconf} -Dlibc=/usr/lib/libc.a"
|
| 202 |
|
|
|
| 203 |
|
|
.. [3] For the purpose of readability, we will refer to 1, 2 and
|
| 204 |
|
|
4-tuples, even though tuple in itself suggest a field consisting of
|
| 205 |
|
|
two values. For clarity: a 1-tuple describes a single value field,
|
| 206 |
|
|
while a 4-tuple decribes a field consisting out of four values.
|
| 207 |
|
|
|
| 208 |
|
|
.. [4] mailto:vapier [at) gentoo .dot org
|
| 209 |
|
|
|
| 210 |
|
|
|
| 211 |
|
|
|
| 212 |
|
|
Copyright
|
| 213 |
|
|
=========
|
| 214 |
|
|
|
| 215 |
|
|
This document has been placed in the public domain.
|
| 216 |
|
|
|
Parent Directory
| 
Revision Log