il problema della gestione delle dipendenze non credo si possa risolvere in slackware: se il repository ufficiale non fornisce le dipendenze di un pacchetto non c'è tool che tenga a mio avviso.
in sostanza il modo in assoluto migliore per gestire le dipendenze è che il pacchettizzatore inserisca una stringa con le stesse all'interno del tgz così che un tool leggendola possa scaricare le dipendenze senza problemi (ovviamente la cosa sarebbe ricursiva). se pat non vuole un gerstore significa come minimo che occorrerebbe mantenere un mirror parallelo a quello di slack in cui inserire ogni volta un file con tutte le dipendenze all'interno di tutti i tgz: non sarebbe il male di sviluppare un tool (in realtà non mi stancherò mai di dire che il tool di base c'è già e si chiama slackpkg : basterebbe un'hackerata per introdurre una funzione per la gestione delle dipendenze) sarebbe il probelma di gestire il mirror dei tgz ufficiali!
la soluzione più pulita a mio avviso sarebbe quella usata anche da slapt-get...
ciò detto secondo me in un ambiente desktop un gestore di dipendenze sarebbe utilissimo!
M
Slackware Package Manager
Moderatore: Staff
Regole del forum
1) Rispettare le idee altrui.
2) Evitare le offese dirette.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
1) Rispettare le idee altrui.
2) Evitare le offese dirette.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
-
absinthe
- Iper Master
- Messaggi: 2354
- Iscritto il: dom 15 mag 2005, 0:00
- Nome Cognome: Matteo Nunziati
- Slackware: 12.1 - defunct
- Kernel: 2.6.32-5-amd64
- Desktop: gnome
- Distribuzione: debian squeeze
- Località: Prato
- Contatta:
[OT]
o meglio ancora usare direttamente:
no eh?!
[/OT]
fico... ma fare:l1q1d ha scritto: Il problema di swaret è che quando fa un upgrade non usa upgradepkg ma remove + install...
Codice: Seleziona tutto
[ `ls /var/log/pakages/ | grep $PKGNAME` ] && upgrade $PKGNAME-$PKGVER-$PKGARCH-$PKGBUILD.tgz || install $PKGNAME-$PKGVER-$PKGARCH-$PKGBUILD.tgz
Codice: Seleziona tutto
upgradepkg --install-new $PKGNAME-$PKGVER-$PKGARCH-$PKGBUILD.tgz
[/OT]
-
absinthe
- Iper Master
- Messaggi: 2354
- Iscritto il: dom 15 mag 2005, 0:00
- Nome Cognome: Matteo Nunziati
- Slackware: 12.1 - defunct
- Kernel: 2.6.32-5-amd64
- Desktop: gnome
- Distribuzione: debian squeeze
- Località: Prato
- Contatta:
beh in riferimento alla gestione delle dipendenze: slapt-get inserisce le dipendenze in una stringa all'interno del tgz quindi ogni tgz contiene le info relative alle proprie dipendenze ed alla versione delle stesse!l1q1d ha scritto:Come fa slapt-get?absinthe ha scritto:la soluzione più pulita a mio avviso sarebbe quella usata anche da slapt-get...
Per quanto riguardo l'OT è vero anche io faccio così, il discorso è che dovrebbe essere implementato da swaret...
so che altri pkg manager invece hanno una gestione un pò diversa tipo un file del repository con la lista di tutte le dipendenze ... non ho mai capito bene come!
personalmente non mi piace il modo in cui le dipendenze sono inserite nel pacchetto (preferirei un file di testo a sè stante contenuto nel tgz) però l'idea sulla carta mi piace molto.
non posso commentare perchè al momento se uso qualcosa utilizzo il mio scriptino (tracepkg) che non risolve le dipendenze ma mi dice subito quali sono quelle mancanti! dico solo che mi sembra un metodo molto pulito e soprattutto a prova di bomba essendo gestito dal pacchettizzatore, teoricamente ricontrollato dall'admin del repository e soprattutto essendo un elenco di dipendenze specifico per quella versione di quel programma!
per la gestione dei conflitti... beh non è così semplice! in teoria è banale far sì che il sistema ti avvisi se stai per aggiornare una libraria attualmente in uso da altri tgz ma il problema è: siamo sicuri che una nuova versione di tale lib crei problemi ai pacchetti che attualmente la utilizzano? oppure l'upgrade non crea problemi?
per quanto rigurada swaret: sono d'accordo dovrebbe essere lo script a fare quello che ho scritto: io una volta ho provato a leggerlo ma mi ci sono perso dentro
M
io non so perche' vi piace tanto swaret, solo ora sta diventando qualcosa chiamato programma, prima era uno script di bash, molti mi dicono "ha lui con i link simbolici risolve le dipendenze -_- si ma e' fatto a muzzo e molte volte canna, inoltre e' molto meno ordinato di slapt-get sulla configurazione"
slapt-get se venisse supportato da tutti come fa slacky sarebbe buonissimo, purtroppo pat gliene sbatte altamente di tutto e continua a fare di testa sua.......... le alternative a slack sono pagliacciate solo arch er ora ci e' andata vicino ma per ora preferisco usare slack
slapt-get se venisse supportato da tutti come fa slacky sarebbe buonissimo, purtroppo pat gliene sbatte altamente di tutto e continua a fare di testa sua.......... le alternative a slack sono pagliacciate solo arch er ora ci e' andata vicino ma per ora preferisco usare slack
Allora, io avevo in mente un tool, che ogniqualvolta l'utente vorrebbe
installare un pacchetto, questo va a leggere un file (scritto da me) in un sito (sotto mio hosting),
recupera i nomi delle dipendenze del pacchetto indicato, dopodiche` va
a scaricare nei mirror ufficiali (e non, se l'utente ne aggiunge degli altri, es. Slacky.it)
le varie dipendenze (possibilmente) all'ultima versione. Infine installa con installpkg.
Questa sarebbe il funzionamento per l'installazione di un pacchetto.
Un sistema potente di gestione dipendenze, non che solo alcuni pacchetti vengano "soddisfatti".
PS: Questo sarebbe anche un modo per non andarsi a buttare senza volerlo in distribuzioni come
ArchLinux o come Frugalware lasciando Slackware, solo per la mancanza di un package manager.
Che mi dite allora?
installare un pacchetto, questo va a leggere un file (scritto da me) in un sito (sotto mio hosting),
recupera i nomi delle dipendenze del pacchetto indicato, dopodiche` va
a scaricare nei mirror ufficiali (e non, se l'utente ne aggiunge degli altri, es. Slacky.it)
le varie dipendenze (possibilmente) all'ultima versione. Infine installa con installpkg.
Questa sarebbe il funzionamento per l'installazione di un pacchetto.
Un sistema potente di gestione dipendenze, non che solo alcuni pacchetti vengano "soddisfatti".
PS: Questo sarebbe anche un modo per non andarsi a buttare senza volerlo in distribuzioni come
ArchLinux o come Frugalware lasciando Slackware, solo per la mancanza di un package manager.
Che mi dite allora?
Riguardo il linguaggio pensavo al C.
Un amico che ho consultato per questo "progetto" mi ha consigliato Python.
Per me e` uguale, solamente che preferivo il tutto programmato in C.
Voi che dite?
Ma sopratutto, pensate che una cosa del genere possa servire e/o sia utile?
La procedura per l'installazione di un pacchetto la ho riportata nel messaggio precedente.
Aspetto vostri consigli e/o critiche.
Un amico che ho consultato per questo "progetto" mi ha consigliato Python.
Per me e` uguale, solamente che preferivo il tutto programmato in C.
Voi che dite?
Ma sopratutto, pensate che una cosa del genere possa servire e/o sia utile?
La procedura per l'installazione di un pacchetto la ho riportata nel messaggio precedente.
Aspetto vostri consigli e/o critiche.
Allora, questo tool non dovrebbe andare a cercare nel pacchetto un file con scritte le dipendenze,
perche` sarebbe impensabile modificare tutti i pacchetti, ma, dicevo,
che questo tool, per ogni pacchetto, va a controllare un file creato apposta da me in un server mio,
in cui sta scritto ogni pacchetto con tutte le sue dipendenze. Quindi non ci sarebbero problemi di inserire nel pacchetto uno
"slack-requires" per esempio. Nessuno non cambierebbe nulla, farebbe tutto controllando delle cose che metto a disposizione io nei "mirror-radice" sul mio server.
Non e` detto che se in un futuro questo tool prendera` un po` di serieta`,
altri siti potrebbero diventare "mirror" dove questo programma andrebbe a cercare nel caso il server principale sia down.
Non so se avete capito, in pratica questi file indirizzerebbero il tool a "raccogliere" le varie dipendenze.
Non ci sarebbe nessun problema, credo. O no?
Alla fine nessuno dovrebbe toccare nulla nei suoi pacchetti.
Comunque ora aspetto altri vostri consigli o critiche, al limite dopo potrei fare uno schemino
del suo funzionamento.
perche` sarebbe impensabile modificare tutti i pacchetti, ma, dicevo,
che questo tool, per ogni pacchetto, va a controllare un file creato apposta da me in un server mio,
in cui sta scritto ogni pacchetto con tutte le sue dipendenze. Quindi non ci sarebbero problemi di inserire nel pacchetto uno
"slack-requires" per esempio. Nessuno non cambierebbe nulla, farebbe tutto controllando delle cose che metto a disposizione io nei "mirror-radice" sul mio server.
Non e` detto che se in un futuro questo tool prendera` un po` di serieta`,
altri siti potrebbero diventare "mirror" dove questo programma andrebbe a cercare nel caso il server principale sia down.
Non so se avete capito, in pratica questi file indirizzerebbero il tool a "raccogliere" le varie dipendenze.
Non ci sarebbe nessun problema, credo. O no?
Alla fine nessuno dovrebbe toccare nulla nei suoi pacchetti.
Comunque ora aspetto altri vostri consigli o critiche, al limite dopo potrei fare uno schemino
del suo funzionamento.
-
absinthe
- Iper Master
- Messaggi: 2354
- Iscritto il: dom 15 mag 2005, 0:00
- Nome Cognome: Matteo Nunziati
- Slackware: 12.1 - defunct
- Kernel: 2.6.32-5-amd64
- Desktop: gnome
- Distribuzione: debian squeeze
- Località: Prato
- Contatta:
quoto l1q1d: l'esperienza di alcuni utenti swaret ha dimostrato che il modo migliore per gestire le dipendenze sia quello di inserire un file in ogni tgz.
per il linguaggio: tieni conto che con un pò di pratica un download e un parse di un file di testo lo si implementa in maniera performante anche con bash usando wget sed/awk! quindi scegli pure il linguaggio che preferisci!
premesso questo direi che se hai voglia di cimentarti comunque prova: magari ne esce qualcosa di più efficace di swaret... la domanda è:
- come fai a definire le dipendenze?
- intendi gestire le dipendenze funzionali o anche quelle "logiche" (tipo definire cdrecord come dipendenza di k3b per intendersi...)?
edit-------
abbiamo postato insieme
dunque. reindirizzare il tool non è sbagliato a priori: l'importante è definire univocamente le dipendenze: specificarle non solo per il pacchetto ma anche per la versione specifica: cioè non limitarsi a dire "mplayer" richiede questo... ma specificare che "mplayer-1.0pre8" richiede questo: così non si sbaglia. inoltre se i repository sono ben fatti converrebbe confinare la ricerca delle dipendenze al repository stesso per evitare di scaricare pacchetti poco compatibili...
M
per il linguaggio: tieni conto che con un pò di pratica un download e un parse di un file di testo lo si implementa in maniera performante anche con bash usando wget sed/awk! quindi scegli pure il linguaggio che preferisci!
premesso questo direi che se hai voglia di cimentarti comunque prova: magari ne esce qualcosa di più efficace di swaret... la domanda è:
- come fai a definire le dipendenze?
- intendi gestire le dipendenze funzionali o anche quelle "logiche" (tipo definire cdrecord come dipendenza di k3b per intendersi...)?
edit-------
abbiamo postato insieme
dunque. reindirizzare il tool non è sbagliato a priori: l'importante è definire univocamente le dipendenze: specificarle non solo per il pacchetto ma anche per la versione specifica: cioè non limitarsi a dire "mplayer" richiede questo... ma specificare che "mplayer-1.0pre8" richiede questo: così non si sbaglia. inoltre se i repository sono ben fatti converrebbe confinare la ricerca delle dipendenze al repository stesso per evitare di scaricare pacchetti poco compatibili...
M
Ultima modifica di absinthe il dom 20 ago 2006, 21:14, modificato 1 volta in totale.
Se no, ancor meglio, ditemi un po' voi come vorreste che sia fatto questo package manager.
Cosa dovrebbe fare, come dovrebbe funzionare, con quali feauture, cosa deve avere in piu` (o in meno) di swaret,
(ovvero cosa ha swaret che non va o cosa gli manca) almeno si provvede a creare un immagine
del tool, dopodiche` si puo` provare a crearlo materialmente.
Cosa dovrebbe fare, come dovrebbe funzionare, con quali feauture, cosa deve avere in piu` (o in meno) di swaret,
(ovvero cosa ha swaret che non va o cosa gli manca) almeno si provvede a creare un immagine
del tool, dopodiche` si puo` provare a crearlo materialmente.
be` alla fine i maggiori repository quali sono..
LinuxPackages.net, Slacky.it, e poi ci sono quelli ufficiali di slackware.it
ma come ho detto prima e` l'utente che sceglie da dove vuole che il tool li prendi.
Per quanto riguarda i file delle dipendenze, pensavo di crearli guardando anche
nei repository di slacky gli slack-requires, o trovare gente disposta a collaborare trovandomi bene tutte le dipendenze di tutti i pacchetti.
No?
@absinthe: Funzionali o logiche sara` definito nel file di configurazione, sara` l'utente a scegliere.
LinuxPackages.net, Slacky.it, e poi ci sono quelli ufficiali di slackware.it
ma come ho detto prima e` l'utente che sceglie da dove vuole che il tool li prendi.
Per quanto riguarda i file delle dipendenze, pensavo di crearli guardando anche
nei repository di slacky gli slack-requires, o trovare gente disposta a collaborare trovandomi bene tutte le dipendenze di tutti i pacchetti.
No?
@absinthe: Funzionali o logiche sara` definito nel file di configurazione, sara` l'utente a scegliere.
Se per questo le utility di pkgtool ( installpkg,upgradepkg,removepkg etc) sono script bash ...IceSlack ha scritto:io non so perche' vi piace tanto swaret, solo ora sta diventando qualcosa chiamato programma, prima era uno script di bash
Che poi l'affidabilità di swaret è decisamente dubbia, concordo.
-
evaimitico
- Linux 1.x
- Messaggi: 140
- Iscritto il: mer 16 giu 2004, 0:00
per come uso io slackware, mi piacerebbe avere un sistema misto tra aptitude ed emerge.
Mi spiego: io potrei volere un certo sw,detto A, che può lavorare con il sw detto B, ma solo se B viene compilato con una opzione che il packager di B non ha attivato. allora mi piacerebbe che il programma mi installase A come pacchetto binario e mi sistemasse B ricompilandolo dai sorgenti( possibilmente stessa versione, o upgrade di essa se necessario). Questo mi farebbe risparmiare un tot di tempo
comunque per gestire bene dipendenze, conflitti, vincoli logici tra pacchetti in maniera proficua senza finire in un Version Hell, a mio avviso conviene creare una sorta di base di conoscenza esterna al pacchetto [poi volendo può essere replicata anche in ogni singolo pacchetto ma non è necessario], che possa essere aggiornabile in via incrementale (non tutti hanno connessione flat o a banda larga: mi farebbe mooolto poco piacere scoprire che dopo aver impiegato mezza giornata per scaricare un pacchetto, se lo installassi potrei rendere inusabile il mio sistema senza scaricare chissà quanta altra roba o per altri motivi esoterici).
Il punto di forza di un sistema misto binario/sorgente, che fosse effettivamente integrato, secondo è che lascerebbe la possibilità di scegliere se compilare o meno in base agli effeettivi tempi della persona: a volte capita di voler fare un upgrade per avere delle feature, ma non si vuole/può attendere ore, per esempio nella compilazione di kde o openoffice.
Inoltre altro aspetto che mi piacerebbe che venisse considerato è il la gestione delle patch per i vari sw, non solo tesi a risolvere bug ma in particolare quelli che aggiungono funzionalità.
discorso linguaggio da usare: dipende dalla complessità dei requisiti :P
Se si punta molto in alto con i requisiti, un linguaggio orientato agli oggetti o agli aspetti
potrebbe ritornare utile, poi libertà totale.
PS come sarebbe l'idea di avere la possibiltà di installare sw in chroot? potrebbe essere figo in ambito server
Mi spiego: io potrei volere un certo sw,detto A, che può lavorare con il sw detto B, ma solo se B viene compilato con una opzione che il packager di B non ha attivato. allora mi piacerebbe che il programma mi installase A come pacchetto binario e mi sistemasse B ricompilandolo dai sorgenti( possibilmente stessa versione, o upgrade di essa se necessario). Questo mi farebbe risparmiare un tot di tempo
comunque per gestire bene dipendenze, conflitti, vincoli logici tra pacchetti in maniera proficua senza finire in un Version Hell, a mio avviso conviene creare una sorta di base di conoscenza esterna al pacchetto [poi volendo può essere replicata anche in ogni singolo pacchetto ma non è necessario], che possa essere aggiornabile in via incrementale (non tutti hanno connessione flat o a banda larga: mi farebbe mooolto poco piacere scoprire che dopo aver impiegato mezza giornata per scaricare un pacchetto, se lo installassi potrei rendere inusabile il mio sistema senza scaricare chissà quanta altra roba o per altri motivi esoterici).
Il punto di forza di un sistema misto binario/sorgente, che fosse effettivamente integrato, secondo è che lascerebbe la possibilità di scegliere se compilare o meno in base agli effeettivi tempi della persona: a volte capita di voler fare un upgrade per avere delle feature, ma non si vuole/può attendere ore, per esempio nella compilazione di kde o openoffice.
Inoltre altro aspetto che mi piacerebbe che venisse considerato è il la gestione delle patch per i vari sw, non solo tesi a risolvere bug ma in particolare quelli che aggiungono funzionalità.
discorso linguaggio da usare: dipende dalla complessità dei requisiti :P
Se si punta molto in alto con i requisiti, un linguaggio orientato agli oggetti o agli aspetti
potrebbe ritornare utile, poi libertà totale.
PS come sarebbe l'idea di avere la possibiltà di installare sw in chroot? potrebbe essere figo in ambito server