# [Tipp] /etc/portage/bashrc für ein package.env missbrauchen

## sirro

Vorwort:

Die Datei /etc/portage/bashrc ist die bashrc, die von portage bei jedem Aufruf der Bash benutzt wird. Angeregt durch diesen Thread habe ich angefangen die Datei für meine Ziele zu missbrauchen  :Wink: 

Im folgendem werde ich das Paket kde-base/kdepim als Beispiel gebrauchen.

Achtung: Der Autor dieser Anleitung übernimmt keine Haftung für Schäden, die durch die Anwendung des Tipps entstehen. Wer nicht weiß was hier gemacht wird sollte im Sinne seines Systems darauf verzichten.

Nichtsdestotrotz: Bei mir tuts der Tipp so wie er hier steht!

Vorgehensweise:

/etc/portage/bashrc anlegen und folgendes eintragen:

```
if [ -z "${CATEGORY}" ] || [ -z "${PN}" ]; then

        PKG_ENV_FILE="/not/exits"

else

        PKG_ENV_FILE="/etc/portage/package.env/${CATEGORY}/${PN}"

fi

if [ -r ${PKG_ENV_FILE}-${PV} ]; then

        source ${PKG_ENV_FILE}-${PV}

elif [ -r ${PKG_ENV_FILE} ]; then

        source ${PKG_ENV_FILE}

fi
```

Nun kann man im Verzeichnis /etc/portage/package.env Verzeichnisse für die Kategorie anlegen. Darin legt man eine neue Datei für kdepim an (/etc/portage/package.env/kde-base/kdepim) und editiert diese.

In unserem Beispiel also:

```
mkdir -p /etc/portage/package.env/kde-base

${EDITOR} /etc/portage/package.env/kde-base/kdepim

Inhalt (z.B.):

        export VARIABLE="--schlagmichtod --irgendwastolles"
```

Bei einem emerge kdepim wird jetzt automatisch über die bashrc die VARIABLE-Variable gesetzt und beim bauen genutzt.

Weitere Tipps

 Die bashrc von oben unterstützt auch verschiedene Versionen eines Programms. z.B.: /etc/portage/package.env/kde-base/kdepim-3.1.5

Dateien mit Versionsnummern werden dabei bevorzugt gegenüber Dateien ohne Versionsnummern behandelt.

 VARIABLE ist natürlich nur ein Beispiel, Im Prinzip ist alle möglich (CFLAGS, FEATURES etc.). Über Sinn und Unsinn möge jeder selbst entscheiden...

Fragen, Ergänzungen, weitere Tipps etc. sind natürlich sehr willkommen.

Edits:

bashrc erweitert, da bei einem unmerge die Variablen nicht gesetzt sind kommt es zu anschönen Fehlermeldungen

Unter http://de.gentoo-wiki.com/TIPP_package.env verfuegbar gemachtLast edited by sirro on Sat Feb 26, 2005 1:11 pm; edited 3 times in total

----------

## Carlo

DO_NOT_COMPILE bricht Abhängigkeiten Wie sollen abhängige Ebuilds erfahren, daß ein Ebuild um "Teile davon" erleichtert wurde, wenn sich dies nicht in den Abhängigkeiten widerspiegelt? Momentan ist DO_NOT_COMPILE böse, um mich mal an Deine Signatur anzulehnen.

----------

## Sas

Ja das stimmt, ist sicher nicht das schlauste Beispiel  :Wink: 

sirro, du hast oben mal Fluxbox geschrieben. Ich weiß ja nicht, ob du das KDE-PIM-Paket für dein Fluxbox erleichtern wolltest, oder ob das einfach ein Fehlerchen ist, aber auf jeden Fall ist es etwas irreführend.

----------

## sirro

 *Carlo wrote:*   

> DO_NOT_COMPILE bricht Abhängigkeiten

 

Ich weiß. (ist ja auch logisch)

Aber da ich DO_NOT_COMPILE eigentlich nur auf top-level-Pakete (also welche, die ganz oben in den Abhängikeiten stehen) anwende wird es wohl kaum dazu kommen. Und wenn, dann ist es halt mein Pech und ich muss nochmal neu kompilieren.

Und wie gesagt: "Wer nicht weiß was hier gemacht wird sollte im Sinne seines Systems darauf verzichten."

Aber als Beispiel wahrscheinlich unglücklich. Hab das ganze jetzt neutral gefasst, soll ja keiner auf dumme Gedanken kommen.

 *Sas wrote:*   

> oder ob das einfach ein Fehlerchen ist

 

Fehlerchen. Ich korregier das mal...

----------

## Carlo

 *sirro wrote:*   

> Aber da ich DO_NOT_COMPILE eigentlich nur auf top-level-Pakete (also welche, die ganz oben in den Abhängikeiten stehen) anwende wird es wohl kaum dazu kommen. Und wenn, dann ist es halt mein Pech und ich muss nochmal neu kompilieren.
> 
> Und wie gesagt: "Wer nicht weiß was hier gemacht wird sollte im Sinne seines Systems darauf verzichten."

 

Im Normalfall sollte es so sein. Je mehr diese Möglichkeit breitgetreten wird, desto wahrscheinlicher wird es jedoch, daß entsprechende "Anwenderfehler" überflüssigerweise in bugs.g.o auftauchen und erstmal ein großes  :Question:  hinterlassen.

----------

## sirro

 *Carlo wrote:*   

> Je mehr diese Möglichkeit breitgetreten wird, desto wahrscheinlicher wird es jedoch, daß entsprechende "Anwenderfehler" überflüssigerweise in bugs.g.o auftauchen und erstmal ein großes  hinterlassen.

 

Da gebe ich dir 100% recht, darum habe ich es auch rausgenommen.

Also: "Don't Try This At Home"    :Wink: 

----------

## hirnstrudel.de

Ich hab das ganze mal ausprobiert, und die Dateien werden auch richtig gefunden, nur werden die dort verwendeten CFLAGS nicht beachtet.

/etc/portage/package.env/net-www/mod_fastcgi

```
export CFLAGS="${CFLAGS} -DSECURITY_HOLE_PASS_AUTHORIZATION"

export CXXFLAGS="${CXXFLAGS} -DSECURITY_HOLE_PASS_AUTHORIZATION"
```

Das zusätzliche define taucht in den Compiler aufrufen einfach nicht auf.

Wo liegt der Hund begraben?

edit: Mir fällt grad auf, es wird auch ignoriert, wenn ich es direkt in der make.conf eintrage.

----------

