Instead of proposing a 4-tuple <aclass="footnote-reference"href="#id4"id="id2"name="id2">[2]</a> keyword, a 2-tuple keyword is chosen

135

for archs that require them. Archs for which a 1-tuple keyword

136

suffices, can keep that keyword. Since this doesn't change anything to

137

the current situation in the tree, it is considered to be a big

138

advantage over the 4-tuple keyword from GLEP 22. This GLEP is an

139

official specification of the syntax of the keyword.</p>

140

<p>Keywords will consist out of two parts separated by a hyphen ('-'). The

141

left hand part of the keyword 2-tuple is the architecture, such as

142

ppc64, sparc and x86. The right hand part indicates the operating

143

system or distribution, such as linux, macos, darwin, obsd, etc. If the

144

right hand part is omitted, it implies the operating system/distribution

145

type is Gentoo GNU/Linux. In such case the hyphen is also omitted.

146

Examples of such keywords are ppc-darwin and x86. This is fully

147

compatible with the current use of keywords in the tree.</p>

148

<p>The variables <ttclass="literal"><spanclass="pre">ELIBC</span></tt>, <ttclass="literal"><spanclass="pre">KERNEL</span></tt> and <ttclass="literal"><spanclass="pre">ARCH</span></tt> are currently set in

149

the profiles when other than their defaults for a GNU/Linux system.

150

They can as such easily be overridden and defined by the user. To

151

prevent this from happening, the variables should be auto filled by

152

Portage itself, based on the <ttclass="literal"><spanclass="pre">CHOST</span></tt> variable. While the <ttclass="literal"><spanclass="pre">CHOST</span></tt>

153

variable can be as easy as the others set by the user, it still is

154

assumed to be 'safe'. This assumption is grounded in the fact that the

155

variable itself is being used in various other places with the same

156

intention, and that an invalid <ttclass="literal"><spanclass="pre">CHOST</span></tt> will cause major malfunctioning

157

of the system. A user that changes the <ttclass="literal"><spanclass="pre">CHOST</span></tt> into something that is

158

not valid for the system, is already warned that this might render the

159

system unusable. Concluding, the 'safeness' of the <ttclass="literal"><spanclass="pre">CHOST</span></tt> variable

160

is based on externally assumed 'safeness', which's discussion falls

161

outside this GLEP.</p>

162

<p>Current USE-expansion of the variables is being maintained, as this

163

results in full backward compatibility. Since the variables themself

164

don't change in what they represent, but only how they are being

165

assigned, there should be no problem in maintaining them. Using

166

USE-expansion, conditional code can be written down in ebuilds, which is

<p>then the following bash script can be used to set the four variables to

214

their correct values:</p>

215

<preclass="literal-block">

216

% cat readmap

217

#!/bin/bash

218

219

CBUILD=${CBUILD:-${CHOST=${CHOST:-$1}}}

220

[[ -z ${CHOST} ]] &amp;&amp; echo need chost

221

222

unset KERNEL ELIBC ARCH

223

224

while read LINE ; do

225

set -- ${LINE}

226

targ=$1

227

shift

228

[[ ${CBUILD} == ${targ} ]] &amp;&amp; eval $&#64;

229

done &lt; env-map

230

231

echo ARCH=${ARCH} KERNEL=${KERNEL} ELIBC=${ELIBC}

232

</pre>

233

<p>Given the example env-map file, this script would result in:</p>

234

<preclass="literal-block">

235

% ./readmap x86_64-pc-linux-gnu

236

ARCH=amd64 KERNEL=linux ELIBC=glibc

237

</pre>

238

<p>The entries in the <ttclass="literal"><spanclass="pre">env-map</span></tt> file will be evaluated in a forward

239

linear full scan. A side-effect of this exhaustive search is that the

240

variables can be re-assigned if multiple entries match the given

241

<ttclass="literal"><spanclass="pre">CHOST</span></tt>. Because of this, the order of the entries does matter.

242

Because the <ttclass="literal"><spanclass="pre">env-map</span></tt> file size is assumed not to exceed the block

243

size of the file system, the performance penalty of a full scan versus

244

'first-hit-stop technique' is assumed to be minimal.</p>

245

<p>It should be noted, however, that the above bash script is a proof of

246

concept implementation. Since Portage is largerly written in Python, it

247

will be more efficient to write an equivalent of this code in Python

248

also. Coding wise, this is considered to be a non-issue, but the format

249

of the <ttclass="literal"><spanclass="pre">env-map</span></tt> file, and especially its wildcard characters, might

250

not be the best match with Python. For this purpose, the format

251

specification of the <ttclass="literal"><spanclass="pre">env-map</span></tt> file is deferred to the Python

252

implementation, and only the requirements are given here.</p>

253

<p>The <ttclass="literal"><spanclass="pre">env-map</span></tt> file should be capable of encoding a <ttclass="literal"><spanclass="pre">key</span></tt>, <ttclass="literal"><spanclass="pre">value</span></tt>

254

pair, where <ttclass="literal"><spanclass="pre">key</span></tt> is a (regular) expression that matches a