Slackware Package Manager

Area di discussione libera.

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.
Avatar utente
absinthe
Iper Master
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:

Messaggio da absinthe »

allora diciamo che la possibilità di installare sorgenti o precompilati è un grosso insieme di problemi.
riferendosi semplicemnte allo scaricamento di precompilati, per focalizzare il primo gruppo di problemi: per ricavare le dipendenze di un software compilato basta usare ldd il problema viene per le dipendenze logiche (altro sottotema) e per tutti i pacchetti interpretati: se uso un tool scritto in perl sapere che mi occorre perl per interpretarlo è il meno: il problema è sapere quante librerie perl devo usare (tipo i bindings gtk etc...). insomma:
1-scaricare sorgenti + slackbuild: da definire
2-scaricare tgz già fatti
2.1-scaricare il tgz da un qualsiasi repository ufficiale o no
2.2-cercare sul server di amn se esiste un file in cui sono descritte le dipendenze _DIRETTE_ (parliamone) attraverso un --update della lista dei files del server (come da mio post precedente)
2.2.1-se esiste scaricare il file delle dipendenze (ascii, banale)
2.2.1.1-installare le dipendenze (ovviamente si può opzionare per non far fare tutto in automatico se uno non lo vuole)
2.2.1.2-procedere _RICORSIVAMENTE_ cercando le dipendenze per le dipendenze...
2.2.2- se non esiste il file delle dipendenze avvertire l'utente che se lo deve fare a manina...
2.x- sottinteso che se uno si installa le dipendenze a manina sarebbe gradito contribuisse ad aggiornare poi il repository del server :)

l'unica cosa che puoi fare in automatico è cercare le dipendenze rinvenibili con ldd (non so come fare con gli interpretati o con dipendenze non indicate da ldd tipo xvidcore per le libdvdcss per capirsi).

per estrarre in automatico quante più info possibili devi installere tutte le dipendenze e poi lanciare uno script ad hoc.
require builder è già buono, altrimenti puoi usare qualcosa sulla falsa riga di quello che uso io per tracepkg (che però ha una funzione leggermente diversa. casomai ti posto la parte di codice relativa però è lunghina per un post): meglio se intanto butti un occhio al pacchetto che loris ha messo in repository

IMHO,
M

Avatar utente
absinthe
Iper Master
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:

Messaggio da absinthe »

l1q1d ha scritto:l'alternativa è creare un buon tool che dal pacchetto compilato riesca ad estrarre le dipendenze
come fare in automatico per gli interpretati? io non conosco metodi... per i binari:
require-builder oppure ...ehm... tracepkg :P (scusa l'autocitazione)

M

Avatar utente
l1q1d
Master
Master
Messaggi: 1862
Iscritto il: lun 21 feb 2005, 0:00
Località: In uno spazio n-dimesionale
Contatta:

Messaggio da l1q1d »

Il problema grosso comunque rimane, riuscire a trovare le dipendenze.
Qualcuno sa come funzionano gli altri programmi di gestione pacchetti?

Avatar utente
amn
Linux 1.x
Linux 1.x
Messaggi: 121
Iscritto il: gio 17 ago 2006, 22:35
Località: Massachusetts

Messaggio da amn »

absinthe ha scritto:1-scaricare sorgenti + slackbuild: da definire
2-scaricare tgz già fatti
2.1-scaricare il tgz da un qualsiasi repository ufficiale o no
2.2-cercare sul server di amn se esiste un file in cui sono descritte le dipendenze _DIRETTE_ (parliamone) attraverso un --update della lista dei files del server (come da mio post precedente)
2.2.1-se esiste scaricare il file delle dipendenze (ascii, banale)
2.2.1.1-installare le dipendenze (ovviamente si può opzionare per non far fare tutto in automatico se uno non lo vuole)
2.2.1.2-procedere _RICORSIVAMENTE_ cercando le dipendenze per le dipendenze...
2.2.2- se non esiste il file delle dipendenze avvertire l'utente che se lo deve fare a manina...
2.x- sottinteso che se uno si installa le dipendenze a manina sarebbe gradito contribuisse ad aggiornare poi il repository del server
Per ora non sembra male.
l1q1d ha scritto:Il problema grosso comunque rimane, riuscire a trovare le dipendenze.
Qualcuno sa come funzionano gli altri programmi di gestione pacchetti?
Scarico i source di apt e vedo un po' che combina. Prima mi faccio una dormita che ho passato la notte in bianco.

Avatar utente
absinthe
Iper Master
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:

Messaggio da absinthe »

l1q1d ha scritto:Il problema grosso comunque rimane, riuscire a trovare le dipendenze.
Qualcuno sa come funzionano gli altri programmi di gestione pacchetti?
gli rpm sono un mistero...

i deb dovrebbero essere archivi ar cointententi in soldoni:
1-una specie di tgz come quello di slack
2-una serie di files che determinano le dipendenze (in termini di pacchetti non di singoli files) e le eventuali operazioni post-installazione

edit------------------------------
ok sono un idiota mi erano sfuggiti i files nascosti :P

i file gestiti da pacman (in riferimento a frugalware) sono dei normali tbz (tar.bzip) come freebsd. ovvero vengono visti da 'file' come un bzip, lo si decomprime e viene visto come un POSIX tar archive: ne ho esploso uno e ho trovato un file nascosto contenente diverse info sul pacchetto incluse le dipendenze...

di più nin zo!

M

Avatar utente
l1q1d
Master
Master
Messaggi: 1862
Iscritto il: lun 21 feb 2005, 0:00
Località: In uno spazio n-dimesionale
Contatta:

Messaggio da l1q1d »

le dipendenze sono date con il nome del pacchetto o con il nome della libreria/programma ovvero:
cdrecord-2.4 o cdrecord-2.4st.tgz?

notsafe
Linux 2.x
Linux 2.x
Messaggi: 451
Iscritto il: mar 21 mar 2006, 11:00

Messaggio da notsafe »

l1q1d ha scritto:Il problema grosso comunque rimane, riuscire a trovare le dipendenze.
Qualcuno sa come funzionano gli altri programmi di gestione pacchetti?
Leggiti i miei commenti in questa discussione:

http://www.slacky.it/forum/viewtopic.php?t=13868


Alcune piccole note:

- che io mi ricorda, swaret non utilizza da molto tempo il file repository per la risoluzione delle dipendenze, ma usa solo la ricerca di librerire tramite ldd, meotdo che quindi non include dipendenze "logiche".

- esiste un port di emerge per Slackware ( e adattabile ad altre distro): http://emerde.freaknet.org/

- il 90% delle vostre idee sono gia state implementate in slapt-get ( http://software.jaos.org/ ) Di conseguenza..perchè re-inventare per l'ennesima volta la ruota? non è meglio aiutare progetti gia esistenti? In fondo è questo il bello del freesoftware.

Avatar utente
absinthe
Iper Master
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:

Messaggio da absinthe »

l1q1d ha scritto:le dipendenze sono date con il nome del pacchetto o con il nome della libreria/programma ovvero:
cdrecord-2.4 o cdrecord-2.4st.tgz?
dunque mi spiego in dettaglio:

1-ho scaricato un file di frugal: binutils-2.17-1-i686.fpm

con un 'tar xjvf' ho estratto i contenuti. oltre alle varie dir come in un tgz, vi sono alcuni file nascosti, incluso un file chiamato: .PKGINFO contenente le dipendenze, espresse solo come pacchetto e non come versione (le binutils fi frugal dipendono dal pacchetto 'bash'): credo che la versione sia relativa alla versione della distro: la frugal 0.4 avrà le sue binutils e la sua bash etc...
eccolo:

Codice: Seleziona tutto

utente@laptop:~/temp$ cat .PKGINFO 
# Generated by makepkg 2.9.8
# Sun Jul 16 13:56:45 CEST 2006
pkgname = binutils
pkgver = 2.17-1
pkgdesc = A set of programs to assemble and manipulate binary and object files
url = http://www.gnu.org/software/binutils/
builddate = Sun Jul 16 11:56:45 2006
packager = Frugalware Linux (http://frugalware.org)
size = 9725577
arch = i686
group = devel
group = devel-core
depend = bash
2- ho fatto lo stesso con debian sarge: binutils_2.15-6_i386.deb

gli archivi deb sono dei gioiellini va detto! vanno estratti con 'ar x nomefile.deb'
all'interno ci sono due tar.gz: uno chamato data e contenente i files in maniera similare ad un tgz ed un altro chiamato control contenete le varie operazioni di pre e post install ed un file chiamato 'control' all'interno del quale sono indicate le dipendenze con nome e versione, eccolo:

Codice: Seleziona tutto

utente@laptop:~/temp$ cat control
Package: binutils
Version: 2.15-6
Section: devel
Priority: standard
Architecture: i386
Depends: libc6 (>= 2.3.2.ds1-21)
Suggests: binutils-doc (= 2.15-6)
Conflicts: gas, elf-binutils, modutils (<< 2.4.19-1)
Provides: elf-binutils
Installed-Size: 5976
Maintainer: James Troup <james@nocrew.org>
Description: The GNU assembler, linker and binary utilities
 The programs in this package are used to assemble, link and manipulate
 binary and object files.  They may be used in conjunction with a compiler
 and various libraries to build programs.
M

Avatar utente
absinthe
Iper Master
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:

Messaggio da absinthe »

notsafe ha scritto:
l1q1d ha scritto:Il problema grosso comunque rimane, riuscire a trovare le dipendenze.
Qualcuno sa come funzionano gli altri programmi di gestione pacchetti?
Leggiti i miei commenti in questa discussione:

http://www.slacky.it/forum/viewtopic.php?t=13868


Alcune piccole note:

- che io mi ricorda, swaret non utilizza da molto tempo il file repository per la risoluzione delle dipendenze, ma usa solo la ricerca di librerire tramite ldd, meotdo che quindi non include dipendenze "logiche".

- esiste un port di emerge per Slackware ( e adattabile ad altre distro): http://emerde.freaknet.org/

- il 90% delle vostre idee sono gia state implementate in slapt-get ( http://software.jaos.org/ ) Di conseguenza..perchè re-inventare per l'ennesima volta la ruota? non è meglio aiutare progetti gia esistenti? In fondo è questo il bello del freesoftware.
vero hai ragione... però questo può valere per amn e l1q1d: io non ce la faccio a mettermi a leggere pagine di codice in 'c': è + forte di me... e l'unica partizione che mi posso permettere per i test al momento la uso per le mie menatine...

e poi slapt-get non risolve le dipendenze dei pacchetti slack ufficiali tanto è vero che fu manutenuta per un certo periodo OCSID.

e comuque ci si diverte un pò ;)

attendo smentite (ovvio)
M

notsafe
Linux 2.x
Linux 2.x
Messaggi: 451
Iscritto il: mar 21 mar 2006, 11:00

Messaggio da notsafe »

absinthe ha scritto: vero hai ragione... però questo può valere per amn e l1q1d: io non ce la faccio a mettermi a leggere pagine di codice in 'c': è + forte di me... e l'unica partizione che mi posso permettere per i test al momento la uso per le mie menatine...
questione di buona volontà e priorità. E poi non serve per forza sapere un linguaggio di programmazione per aiutare un progetto.
e poi slapt-get non risolve le dipendenze dei pacchetti slack ufficiali tanto è vero che fu manutenuta per un certo periodo OCSID.
*nessun* programma attuale risolve realmente le dipendenze e *nessun* programma lo farà mai *se* non viene implementato nativamente nel sistema di package ( come lo è per rpm, per deb etc). Nel sistema di package di Slackware *non* è implementato, ergo *non* sarà mai possibile risolvere realmente le dipendenze.

Se si vuole portare avanti un progetto, si deve partire da questo presupposto.

Nello specificho, se leggi le FAQ di slapt-get:

" Also, Stefano Stabellini has created a PACKAGES.TXT that contains the
dependency information for Slackware packages without modifying the actual
packages themselves. This can be used as a slapt-get source to pull the
packages from official slackware.com mirrors. Read more about it at
Stefano's page: http://www.stabellini.net/depslack.html"

Un buon proposito sarebbe quello di contattare Stabellini e vedere se è possibile tenere attivo questo sistema ( ovviamente per chi può interessare )
Ultima modifica di notsafe il lun 21 ago 2006, 16:49, modificato 1 volta in totale.

Avatar utente
l1q1d
Master
Master
Messaggi: 1862
Iscritto il: lun 21 feb 2005, 0:00
Località: In uno spazio n-dimesionale
Contatta:

Messaggio da l1q1d »

Ho provato emerde e ho dovuto formattare il sistema perchè mi aveva fatto un casino impossibile!

Avatar utente
absinthe
Iper Master
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:

Messaggio da absinthe »

notsafe ha scritto: questione di buona volontà e priorità. E poi non serve per forza sapere un linguaggio di programmazione per aiutare un progetto.
sono d'accordo ho ben evidente che è solo una questione di pigrizia, ma non posso farci niente: non ne ho voglia e come si dice dalle mie parti " per forza non si fa nemmeno l'aceto"!
*nessun* programma attuale risolve realmente le dipendenze e *nessun* programma lo farà mai *se* non viene implementato nativamente nel sistema di package ( come lo è per rpm, per deb etc). Nel sistema di package di Slackware *non* è implementato, ergo *non* sarà mai possibile risolvere realmente le dipendenze.
non sono d'accordo: basta costruire le dipendenze per tgz e mantenerle... non è necessario che l'elenco delle dipendenze sia fisicamente inserito nel pacchetto basta che sia riferibile ad esso in maniera univoca IMHO
Nello specificho, se leggi le FAQ di slapt-get:

" Also, Stefano Stabellini has created a PACKAGES.TXT that contains the
dependency information for Slackware packages without modifying the actual
packages themselves. This can be used as a slapt-get source to pull the
packages from official slackware.com mirrors. Read more about it at
Stefano's page: http://www.stabellini.net/depslack.html"

Un buon proposito sarebbe quello di contattare Stabellini e vedere se è possibile tenere attivo questo sistema ( ovviamente per chi può interessare )
credo faccia riferimento appunto ad OCSID: mantenere tale progetto significa aggiungere il supporto alle dipendenze anche per il set di tgz ufficiali senza intaccarli! in effetti questo è l'equivalente di quello di cui stavamo parlando.

tuttavia tornando al discorso del "free" cui accennavi: se amn preferisce aiutare il progetto slapt-get è giusto che lo faccia ma è altrettanto giusto che -se preferisce- ne cominci uno proprio. se l'idea di fare un nuovo tool nasce dal non conoscere slapt-get magari adesso può ripensare la sua idea altrimenti è libero di gestire il suo tempo libero diversamente (ma credo che su questo si sia tutti d'accordo in realtà... è solo per precisare)

M

evaimitico
Linux 1.x
Linux 1.x
Messaggi: 140
Iscritto il: mer 16 giu 2004, 0:00

Messaggio da evaimitico »

io focalizzerei bene il discorso dipendenze, soprattutto che tipi di dipendenza vi sono fra i programmi.

In mente mi vengono i seguenti casi:
diretta: il sw A non compila senza il sw B o non funziona senza B
optional soft: il sw A, se presente B, offre funzionalità in più
optional hard: il sw A, se compilato con un'apposita opzione e se presente B, offre funzionalità in più

Inoltre la cosa più problematica e difficile da tracciare nelle dipendenze è che per ogni programma variano nel tempo col crescere delle versioni. inoltre possono esserci conflitti o che siano richieste particolari versioni di un sw stesso.
In quest'ottica, il file aggiunto nel pacchetto ti esprime le reali ( e storiche dipendenze ) di un pacchetto. Mantenere però queste informazioni solo nel pacchetto è limitativo, perché non ti permetterebbe di calcolare a priori le conseguenze dell'installazione di un pacchetto: finché non lo scarico non posso sapere che cosa richiede per funzionare.
Per questo io metterei le info dettagliate nel pacchetto, ma anche distribuite su un network di server, dal quale scaricare la lista dei pacchetti e delle dipendenze. Qui ci sarebbe da discutere un bel po' su come memorizzare tali info e come dovrebbe procedere l'upgrade. l'optimum sarebbe un modo che permette di scaricare solamente le differenze che vi sono rispetto alle info che ho in cache ( tanti file diff? oppure un file generato al volo con tutti gli aggiornamenti rispetto ad un certa data? )
Ovviamente per mantenere le info delle dipendenze sia nei pacchetti che nei repository possiamo prevedere dei tool automatici

ultimamente ho provato ad usare nuovamente debian: è stata la mia prima distribuzione (woody, a dir la verità), ma è durata un paio di giorni sul mio computer per l'allucinante mondo delle dipendenze OBBLIGATE. dopo tale esperienza ho provato slackware e il fatto che non fossi sempre obbligato ad installare un mare di sw mi ha reso contento. recentemente ho provato sarge, e devo dire che aptitude, unito a dpkg-reconfigure mi ha dato una impressione molto buona. In Debian hanno inoltre iniziato a realizzare i pacchetti a slice, in modo da ridurre il numero di dipendenze per il pacchetto principale. se slackware permettesse, quando si vuole espressamente di gestire le dipendenze, sarei l'uomo più felice della terra :)
Ad ogni modo l'attuale gestione debian può servire come spunto, in particolare per la varietà di tipi di dipendenza che individua.

Un dubbio: possono esserci dipendenze circolari?

notsafe
Linux 2.x
Linux 2.x
Messaggi: 451
Iscritto il: mar 21 mar 2006, 11:00

Messaggio da notsafe »

absinthe ha scritto: non sono d'accordo: basta costruire le dipendenze per tgz e mantenerle... non è necessario che l'elenco delle dipendenze sia fisicamente inserito nel pacchetto basta che sia riferibile ad esso in maniera univoca IMHO
Se i principali sistemi di package che contemplano il check di dipendenze ( in primis quindi RPM e DEB) imagazzinano tale informazioni nel pacchetto stesso, ci sarà pure un buon motivo,no? Con tutto il rispetto, ma gli ingegneri del software che hanno sviluppato sistemi tanto portabili da diventare standard de facto hanno un pò di esperienza sulle spalle.

Questo non vuol dire che un sistema di elenco di dipendenze in un file sia "inutile",ma per come la vedo io è fallace ( se non hai la possibilità di consultare tale file cosa succede? impedisci l'installazione? e se non la impedisci ma il pacchetto va in conflitto con qualche altro pacchetto? non sono cosi banali come domande da porsi se si vuole progettare un utility di package )
credo faccia riferimento appunto ad OCSID: mantenere tale progetto significa aggiungere il supporto alle dipendenze anche per il set di tgz ufficiali senza intaccarli! in effetti questo è l'equivalente di quello di cui stavamo parlando.
Non centra OCSID, anche se prima della "morte" di tale progetto veniva utilizzato. Il concetto rimane comunque quello: non è un sistema "coerente" in quanto è parallelo al sistema ufficiale di package di slackware.
tuttavia tornando al discorso del "free" cui accennavi: se amn preferisce aiutare il progetto slapt-get è giusto che lo faccia ma è altrettanto giusto che -se preferisce- ne cominci uno proprio. se l'idea di fare un nuovo tool nasce dal non conoscere slapt-get magari adesso può ripensare la sua idea altrimenti è libero di gestire il suo tempo libero diversamente (ma credo che su questo si sia tutti d'accordo in realtà... è solo per precisare)
La mia è un opinione,non un obbligo. Credo che sia meglio "unire" le menti in un progetto, piuttosto che dividersi in una miriade idee. Ma questo esula dal discorso.

Avatar utente
absinthe
Iper Master
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:

Messaggio da absinthe »

notsafe ha scritto: Se i principali sistemi di package che contemplano il check di dipendenze ( in primis quindi RPM e DEB) imagazzinano tale informazioni nel pacchetto stesso, ci sarà pure un buon motivo,no?
certo: è la cosa migliore da fare se uno decide di dare supporto alla gestione delle dipendenze: è inutile fare un tool che deve scaricare 2 files aventi stesso nome da 2 server diversi, tanto vale mettere tutto insieme.
Con tutto il rispetto, ma gli ingegneri del software che hanno sviluppato sistemi tanto portabili da diventare standard de facto hanno un pò di esperienza sulle spalle.
per carità: mica penso che qui si stia parlando di inventare un nuovo standard: si parlava di come fare ad "aggirare" la carenza di un gestore integrato di dipendenze in slack: è un accorcchio per definizione!
Questo non vuol dire che un sistema di elenco di dipendenze in un file sia "inutile",ma per come la vedo io è fallace ( se non hai la possibilità di consultare tale file cosa succede? impedisci l'installazione? e se non la impedisci ma il pacchetto va in conflitto con qualche altro pacchetto? non sono cosi banali come domande da porsi se si vuole progettare un utility di package )
beh... è come dire che scarichi il data.tar.gz da una parte e il control.tar.gz da un'altra: se non esiste il file lo indichi nel prompt in fase di d.load prima dell'installazione: poi se uno vuol installare il tgz senza saperne nulla può comunque farlo: è quello che accade adesso. si può tranquillamente mandare in conflitto alcuni tgz se non si sta attenti a quello che si fa.... basta anche solo fare un installpkg pinco-1.0 e poi un installpkg pincoo-2.0 anzichè upgradare... o aggiornare una lib ad una versione non supportata da certi applicativi già installati...
comunque ripeto che non penso -per parte mia- di essere un buon project manager ma semplicemente di trovare una cosa interessante da fare in certi momenti del tempo libero. d'altra parte il mio lavoro è un altro questo lo prendo come un passatempo, senza avere la pretesa di produrre nulla di particolarmente valido da rimanere nella storia.
Non centra OCSID, anche se prima della "morte" di tale progetto veniva utilizzato. Il concetto rimane comunque quello: non è un sistema "coerente" in quanto è parallelo al sistema ufficiale di package di slackware.
beh che dire... sono d'accordo (vedi sopra)!

M

Rispondi