Problemi con i package FFmpeg 20081129 e X264 20081129

[d4z_c0nf]

...Collezione di script. L'ha fatto absinthe.
http://www.slacky.eu/index.php?option=c ... &Itemid=65
rock

E' interessante, ma non è quello che intendo io. Se vedi un mio post più in alto, spiegavo che tutto si può fare con degli script, ma non è la stessa cosa.
Inoltre, da quello che ho letto nell'intro, lo script sembra non tener presente i programmi front-end di altri programmi. Tramite ldd non si può capire se un programma necessita di un altro eseguibile.
Il progetto dovrebbe essere ambizioso a tal punto da spingere anche PJV ad includere chiamate al software negli script di gestione dei pacchetti slackware. Solo a quel punto si avrebbe un sistema di gestione di dipendenze veramente carino.

Il punto è sempre lo stesso, il gioco vale la candela? Cioè, io posso anche iniziare a scrivere codice, ma serve veramente ?

Spina

Mmm, sarebbe comodo, non so PJV quanto lo possa apprezzare.
In ogni caso credo che molti di noi lo useremmo.
rock

[targzeta]

...
Mmm, sarebbe comodo, non so PJV quanto lo possa apprezzare.
In ogni caso credo che molti di noi lo useremmo.
rock

Il programma è già in mente ma è pieno di strutture dati diversificate e mi fa un pò paura, soprattutto perchè non ho molto tempo libero. Comunque vediamo che si può fare, piano piano.

Spina

[d4z_c0nf]

...
Mmm, sarebbe comodo, non so PJV quanto lo possa apprezzare.
In ogni caso credo che molti di noi lo useremmo.
rock

Il programma è già in mente ma è pieno di strutture dati diversificate e mi fa un pò paura, soprattutto perchè non ho molto tempo libero. Comunque vediamo che si può fare, piano piano.

Spina

Magari se vuoi, se lo ritieni opportuno ti potremmo dare una mano, ovviamente non sono minimamente al tuo livello, ma l'impegno non mancherebbe.
rock

[conraid]

Stamattina mi sono svegliato con questo pensiero in testa. Risolvere il problema delle dipendenze una volta per tutte! Si sa che altre distribuzioni risolvono le dipendenze, ma che vuol dire di preciso "risolvere le dipendenze"?
Putroppo o per fortuna conosco solo la Slackware, e quindi non ho idea di cosa facciano le altre distribuzioni.

Non so le altre distribuzioni, ma per esempio OpenBSD, che usa pacchetti .tgz come Slackware (anche in quel caso si decomprimono in /) ci sono degli script accessori, come in Slackware
per esempio c'è +DISPLAY che è come un doinst.sh, +DESC che è come slack-desc e poi c'è un +CONTENTS che contiene il nome del programma, la dimensione, l'md5 di tutti i file inclusi, varie altre cose e le dipendenze. Queste sono segnalate in due modi:
depend, che mostra i programmi da cui dipende
wantlib, le librerie che richiede
Qesta cosa che in Slackware non è gestita ed i programmi che la usano si fanno una voce apposita in PACKAGES.TXT che si chiama SLACK-REQUIRED (mi sembra, o qualcosa di simile)
Basterebbe aggiungere una cosa di simile in ogni pacchetto (così posso usare i normali installpkg, etc... senza dipendere da software di dubbio gusto che leggono PACKAGES.TXT)
In pratica ogni pacchetto sa cosa gli serve e quindi va a prenderselo (in OpenBSD non c'è nessuna locazione perché prendi solo dai mirror ufficiali) dai mirror che abbiano indicato in un qualche file in /etc
In pratica il file .meta (che serve appunto per creare il file PACKAGES.TXT) andrebbe incluso nel .tgz, e poi fare in modo che gli script vada a leggerlo
Faccio presente che uno script per creare i file .meta è fatto da Alien Bob del team Slackware, quindi non è proprio eresia (anche se c'è da dire che lo script prevede la presenza di REQUIRED ma lo lascia vuoto). Ma del resto Alien Bob è quello che spinge per mettere PAM dentro la Slackware, il meno ortodosso del team mi sembra di capire

Come dici giustamente tu, vale la pena tutto questo? Non so rispondere, so che una "forte" dipendenza non mi piacerebbe. Con forte dipendenza intendo dire quel caso in cui togli una libreria (magari perché vuoi ricompilarti da solo per motivi tuoi) e mezzo sistema si vuole cancellare ed il gestore pacchetti va in tilt

[targzeta]

...Come dici giustamente tu, vale la pena tutto questo? Non so rispondere, so che una "forte" dipendenza non mi piacerebbe. Con forte dipendenza intendo dire quel caso in cui togli una libreria (magari perché vuoi ricompilarti da solo per motivi tuoi) e mezzo sistema si vuole cancellare ed il gestore pacchetti va in tilt

No no, io non intendevo dire niente di tutto questo. Il programma è solo un database di informazioni e nient'altro. L'integrazione degli script di installazione dovrebbe esserci solo per aggiornare il database e non per risolvere dipendenze. E' ovvio che su distribuzioni che gestiscono le dipendenze questo può essere usato anche per eliminare o installare altri pacchetti. Ma non è questo lo scopo. L'idea è semplicemente rispondere a delle domande, quelle che ho scritto in post precedenti.

L'uso del require a mio avviso non porta a niente di buono, è complicato per chi crea il pacchetto dover stare sempre a scrivere da quale pacchetto dipende il suo programma. A volte si sceglie di linkare il programma con un altra libreria, e allora si deve rimodificare il require. Invece con questo programma si dovrebbe poter sapere in ogni momento se tutto il software presente sulla propria macchina ha tutto il necessario per poter partire. Inoltre, che poi è la questione del thread, si può sapere, quali programmi sono stati influenzati dalla ricompilazione personale di una determinata libreria. Vedi la libdvdread ad esempio, scoprire ora quali programmi sono linkati a quella libreria non è semplice. Invece con questo programma noi potremmo sapere chi la usa e quindi quali programmi tenere d'occhio se si aggiorna la libreria.

Spina

[fAu]

Come dici giustamente tu, vale la pena tutto questo? Non so rispondere, so che una "forte" dipendenza non mi piacerebbe. Con forte dipendenza intendo dire quel caso in cui togli una libreria (magari perché vuoi ricompilarti da solo per motivi tuoi) e mezzo sistema si vuole cancellare ed il gestore pacchetti va in tilt

intendi qualcosa del genere?

root@gh:/home/fau# slapt-get --remove libdvdread
Reading Package Lists... Done
The following packages will be REMOVED:
k3b libdvdread
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After unpacking 12.4MB disk space will be freed.
Do you want to continue? [y/N]

[conraid]

intendi qualcosa del genere?

root@gh:/home/fau# slapt-get --remove libdvdread
Reading Package Lists... Done
The following packages will be REMOVED:
k3b libdvdread
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After unpacking 12.4MB disk space will be freed.
Do you want to continue? [y/N]

Sì, perché deve togliermi k3b?
Magari io quella libreria ce l'ho non pacchettizzata
Certo, posso dirgli di no, etc... ma un po' rompe
Ricordo che in red-hat usavo spesso --no-check-dependencies (o non ricordo, ma qualcosa di simile), perchè mi piaceva compilarmi molte cose da solo.
Se facessi

Codice: Seleziona tutto

# slapt-get --remove glibc

immagina il casino
E magari ho le glibc ricompilate con gli headers del nuovo kernel, senza essere pacchettizzate

No no, io non intendevo dire niente di tutto questo. Il programma è solo un database di informazioni e nient'altro.

Capito, una "specie" di localedb, ma solo per le dipendenze? Così so sempre da cosa dipende un programma, ma non incide sugli script di installazione e rimozione?

[targzeta]

...Così so sempre da cosa dipende un programma, ma non incide sugli script di installazione e rimozione?

L'idea è che il programma deve andare bene per qualsiasi distribuzione e per qualsiasi tipo di pacchetto. Ogni distro-mantainer dovrebbe implementare una piccolissima parte del progetto. Il programma dovrebbe essere diviso in due parti

• creazione/modifica del database
• interrogazione del db

la seconda è generica, ma la prima dipende dalla struttura della distribuzione. In pratica ci sarebbero delle API da implementare tipo:

• dammi la lista dei pacchetti presenti sul sistema
• io ti passo un pacchetto e tu dammi l'elenco delle librerie e dei binari che contiene

questa parte è ovviamente diversa per ogni distribuzione, sta al mantainer stabilire come implementare queste funzioni per la propria distribuzione. Il resto invece è generale, per ogni pacchetto vengono create tutta una serie di strutture dati che mantengono le informazioni. La relazione di dipendenza invece è espressa tramite una matrice quadrata binaria, dove alla riga i-esima e alla colonna j-esima corrisponde lo stesso binario/libreria. Se la cella (i,j)=1 allora il programma alla riga i ha dipende del programma alla colonna j. In questo modo se si vuole sapere da chi dipende il prigramma X basta seguire la riga associata, mentre se si vuole sapere chi dipende dal programma X basta seguire la colonna associata. Il punto è, che nonostante la matrice sia binaria, all'aumentare dei programmi/librerie aumenta anche la matrice, e non so sino a quando tutto questo diventi accettabile prima di passare a gestire matrici su disco (il che rallenta di tanto). Ad esempio se si hanno 1024=2^10 tra librerie e programmi, la matrice occupa 2^10*2^10bit, ovvero 2^20/2^3/2^10=128Kb e sino a qui è anche accettabile, ma io ad esempio ho già 1713 binari e penso di avere una distribuzione minima rispetto all'utente classico. Questo discorso vale solo per la matrice delle dipendenze, ma poi ci sono altre strutture dati associate ad ogni programma.

Insomma, se diventano molti dati va a finire che bisogna gestirli da disco fisso, suddividendo la matrice in pagine e caricando in memoria solo le pagine strettamente necessarie. Ma qui le cose si complicano.

Inoltre, il programma dipenderebbe dagli script di installazione/rimozione solo per l'aggiornamento del database. Se si aggiunge un pacchetto bisognerebbe informare il db di questo, stessa cosa vale se si rimuove il pacchetto, ecco perchè dovrebbero esserci delle chiamate all'interno di questi script.

Spina

[conraid]

Si sta andando un po' OT, ma hai mai dato un occhiata a smart?
http://labix.org/smart

Adesso KPackage di KDE4 si appoggia a questo tool, scritto in python
Quando chiesi informazioni per dire che lo avevo pacchettizzato per la Slackware mi fu detto che c'è un ramo di sviluppo apposito perché era la distribuzione su cui erano un po' indietro e con qualche problema