| View previous topic :: View next topic |
| Author |
Message |
sirro
Veteran
Joined: 20 Jul 2003
Posts: 1472
Location: aachen.nrw.de.eu
|
 Posted: Sun Jul 18, 2004 4:36 pm Post subject: [Tipp] /etc/portage/bashrc für ein package.env missbrauchen |
 |
|
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 
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:
| Code: | 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:
| Code: | 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:
Last edited by sirro on Sat Feb 26, 2005 1:11 pm; edited 3 times in total |
|
| Back to top |
|
 |
Carlo
Developer
Joined: 12 Aug 2002
Posts: 3356
|
| Posted: Sun Jul 18, 2004 8:39 pm Post subject: |
|
|
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.
_________________
Please make sure that you have searched for an answer to a question after reading all the relevant docs. |
|
| Back to top |
|
|
Sas
Veteran
Joined: 05 Jul 2003
Posts: 1229
Location: Germany
|
| Posted: Sun Jul 18, 2004 9:01 pm Post subject: |
|
|
Ja das stimmt, ist sicher nicht das schlauste Beispiel
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.
_________________
42 |
|
| Back to top |
|
|
sirro
Veteran
Joined: 20 Jul 2003
Posts: 1472
Location: aachen.nrw.de.eu
|
| Posted: Sun Jul 18, 2004 9:07 pm Post subject: |
|
|
| 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... |
|
| Back to top |
|
|
Carlo
Developer
Joined: 12 Aug 2002
Posts: 3356
|
| Posted: Sun Jul 18, 2004 9:48 pm Post subject: |
|
|
| 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  hinterlassen.
_________________
Please make sure that you have searched for an answer to a question after reading all the relevant docs. |
|
| Back to top |
|
|
sirro
Veteran
Joined: 20 Jul 2003
Posts: 1472
Location: aachen.nrw.de.eu
|
| Posted: Sun Jul 18, 2004 9:53 pm Post subject: |
|
|
| 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" |
|
| Back to top |
|
|
hirnstrudel.de
n00b
Joined: 17 Nov 2004
Posts: 40
|
| Posted: Tue Dec 14, 2004 1:37 pm Post subject: |
|
|
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
| Code: | 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. |
|
| Back to top |
|
|
|
Deutsches Forum (German)
