Moderator: ago
Mi sembra una buona idea; domani testo un po' e aggiungo in cvs. Grazie!comio wrote:farei inoltre queste modifiche al perpackage.module:
.non mi sembra tropo complesso:Ferdinando wrote:Mi sembra una buona idea; domani testo un po' e aggiungo in cvs. Grazie!comio wrote:farei inoltre queste modifiche al perpackage.module:
Btw, avete letto che con il nuovo portage /etc/portage/package.* possono essere anche delle dir? Non credo che supporterò mai questo, però
Ciao
Code: Select all
parseconffile_or_dir() {
if [[ -d $1 ]]; then
for file_or_dir in `ls $1`; do
parseconffile_or_dir $file_or_dir
done
else
parseconffile $1
fi
}
Come? Perché? /etc/portage dovrebbe essere in CONFIG_PROTECT, e oltretutto l'ebuild non dovrebbe installare bashrc-ng.conf, ma bashrc-ng.conf.example... Uhm, ora ci guardo un po'...k.gothmog wrote:CONFIG_PROTECT!!!!
le impostazioni che avevo fatto a mano in bashrc-ng.conf se ne sono allegramente andate a fare in c**o
) ho conficurato tutto con eselect e va bene Code: Select all
>=sys-apps/coreutils-5.96
>=sys-devel/patch-2.5.9Code: Select all
sys-apps/coreutils
sys-devel/patch
stessa cosa che ho chiesto io, ma @philantrop vorrebbe tenerle.fabius wrote:C'è qualche motivo particolare per richiedere tra le dipendenzeCode: Select all
>=sys-apps/coreutils-5.96 >=sys-devel/patch-2.5.9
Pensa che scemo, io avevo scritto la stessa esatta cosa in un mio script bash quando c´era già in giro enotice! Lavoro sprecato, sigh... Io però non saprei come realizzare la cosa in un bashrc, magari vedo un po´ cosa fa enotice di preciso.Onip wrote:L'idea è che al termine dell'emerge complessivo di n pacchetti venga lanciato enotice in modo da poter rivedere i vari avvisi
Non lo conoscevo, ma leggendo make.conf.example pare proprio di sì. Al prossimo aggiornamento lo provofabius wrote:Domanda scema: ora enotice non è superato con il supporto ELOG di portage?
Grazie per la segnalazione; ci guarderò appena possibile. Non mi meraviglia che non me ne sia mai accorto; sul mio sistema gli unici jar appartengono a dei binari...Wise wrote:i pacchetti incriminati sono commons-lang,commons-cli e swt, ma secondo me hanno lo stesso
problema anche tutti i commons-* e in generale tutti i pacchetti che installano librerie java...
effettivamente questo effetto mi capitava... ma non ho pensato al bashrc...Ferdinando wrote:Grazie per la segnalazione; ci guarderò appena possibile. Non mi meraviglia che non me ne sia mai accorto; sul mio sistema gli unici jar appartengono a dei binari...Wise wrote:i pacchetti incriminati sono commons-lang,commons-cli e swt, ma secondo me hanno lo stesso
problema anche tutti i commons-* e in generale tutti i pacchetti che installano librerie java...
Grazie ancora
Ciao
mi ci sono imbattuto anche io tempo fa, stessi sintomi, ma pensavo fosse un problema del pacchetto che stavo installando e non di bashrc, tant'è che ho aperto pure un bugreport: http://bugs.gentoo.org/show_bug.cgi?id=138589Wise wrote:penso di aver riscontrato un problema con bashrc-ng e i pacchetti che hanno a che fare con il java:
in presenza del file bashrc la compilazione del pacchetto e la compilazione vengono portate a termine...
Ho il sospetto che alcune versioni di qualche pacchetto facciano dei giochetti strani con le variabili d'ambiente (il bashrc non fa molto), ma vi saprò dire solo domani, dopo aver emerso i pacchetti incriminati.!equilibrium wrote:il problema si è risolto installando la versione unstable di quel pacchetto e delle JDK.
a naso mi pare un problema con i permessi o con le coreutils, non vorrei che l'uso dell'ebuild che forzava la versione unstable delle coreutils fosse la causa. In caso, abbiamo un altro valido motivo per non usare coreutils ~x86 e fare un bugreport del problema.Ferdinando wrote:Ho il sospetto che alcune versioni di qualche pacchetto facciano dei giochetti strani con le variabili d'ambiente (il bashrc non fa molto), ma vi saprò dire solo domani, dopo aver emerso i pacchetti incriminati.
Code: Select all
diff -wu bashrc bashrc.new
--- bashrc 2006-07-01 15:50:23.086252000 +0200
+++ bashrc.new 2006-07-11 21:18:07.112540500 +0200
@@ -116,7 +116,7 @@
for mod in ${MODULESDIR}/*.module
do
# define an empty action
- eval "$EBUILD_PHASE () {
+ eval "on_$EBUILD_PHASE () {
true
}"
# source the module, if active
@@ -125,7 +125,7 @@
then
source $mod
# invoke the module-defined action, if any
- $EBUILD_PHASE
+ on_$EBUILD_PHASE
fi
doneio sarei per rinominarle in modo del tipo bashrc_clean(), bashrc_setup(), ... così dovrebbe essere realmente difficile fare collisione.Ferdinando wrote:che potete applicare andando in /etc/portage, scrivendo 'patch -p0' e poi facendo copia-incolla del testo qui su (terminato con ctrl-D); il problema è che bisogna poi aprire in un editor ogni modulo (almeno quelli che usate, nella prossima release saranno tutti corretti) e sostituire clean() con on_clean(), setup() con on_setup(), compile() con on_compile(), install() con on_install(), e postinst con on_postinst(); dovrebbero essere le ultime funzioni in ogni modulo.
Ciao
Ci avevo pensato ma mi sembra un po' tristecomio wrote:io sarei per rinominarle in modo del tipo bashrc_clean(), bashrc_setup(), ... così dovrebbe essere realmente difficile fare collisione.
Per ora credo che on_ vada bene, magari prima che esca la nuova release ci penso su.