Slackware Package Manager

[absinthe]

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ù

non ho mica capito la differenza... :/

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

beh... basta che il tool _PRIMA_ di installare (e in questo caso prima di scaricare il tgz) verifichi le richieste di tale file (e le altre in cascata). sul fatto che una versione di una lib possa creare conflitti, beh il problema è uguale in tutte le distro per questo in realtà dovrebbe essere il pacchettizzatore a definire le dipendenze in base ai dati forniti dal programmatore (e magari qualcuno dovrebbe controllare l'esattezza dei dati)
tool automatici che riescano a fare sta cosa senza il minimo intervento umano non ne conosco... mi sembrano anche un pò pericolosi...

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.

mai usato debian ma che intendi per dipendenze obbligate? voglio dire: se vuoi far partire mplayer anche la slack rchiede un bel pò di tgz...

Un dubbio: possono esserci dipendenze circolari?

dopo attenta riflessione direi... BOH!
in teoria vorrebbe dire aver bisogno degli header di A per compilare B e viceversa... ma allora non si tratterebbe di due parti di codice contenute nello stesso programma?
solitamente si ricorre alle "dipendenze" di esecuzione perchè per comodità si utilizza nel proprio software elementi già creati da altri e non perchè in contemporanea si cerca di realizzare due binari tra loro collegati per funzionalità... io personalmente non ricordo se ne ho trovate... devo dare un occhio quando riaccendo il portatile...

M

[amn]

Concordo con notsafe sul fatto che se debba fare un tool con le stesse funzionalita` di slapt-get,
tanto vale aiutare nel progetto lo stesso slapt-get.
Il problema e` questo, bisognerebbe creare un tool che abbia qualcosa in piu`, che possa
riparare i mancamenti di swaret o di slapt-get, in campo installazione, rimozione e upgrade.
Bisogna pensarci, bisogna vedere se si riesce a pensare come
dovrebbe essere fatto un tool che "ripari" o che "toppi" alcuni buchi che ci sono nei tool gia` esistenti per Slackware.
Come gestire in maniera *migliore* questo fatto delle dipendenze.
Se proprio non si potra` mai gestirle in maniera divina su Slackware, almeno trovare un modo
per gestirle in una maniera migliore di quanto lo facciano ora swaret, slapt-get e gli altri.
Una possibilita` sarebbe quella di *vedere* in sopraluogo il codice di apt,
anche se non sara` mai uguale visto che lavora con dei pacchetti Debian "fatti apposta" per saziare dipendenze (come dicevate prima).

[evaimitico]

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ù

non ho mica capito la differenza... :/

nel secondo caso, a differenza del primo, è obbligatoria la ricompilazione per fruire di funzionalità in più.

beh... basta che il tool _PRIMA_ di installare (e in questo caso prima di scaricare il tgz) verifichi le richieste di tale file (e le altre in cascata).

però per verificare le dipendenze prima di scaricare il tool, vuol dire che ha reperito da qualche parte (magari la copia cache di un qualche server remoto) quali sono le dipendenze, e questa è la soluzione che suggerivo: info sulle dipendenze sia nel pacchetto, che remotamente accessibili.

[absinthe]

nel secondo caso, a differenza del primo, è obbligatoria la ricompilazione per fruire di funzionalità in più.

se non è necessario ricompilare allra stiamo parlando di dipendenze logiche e non funzionali... giusto?

però per verificare le dipendenze prima di scaricare il tool, vuol dire che ha reperito da qualche parte (magari la copia cache di un qualche server remoto) quali sono le dipendenze, e questa è la soluzione che suggerivo: info sulle dipendenze sia nel pacchetto, che remotamente accessibili.

ah! in effetti credo che amn parlasse di realizzare un repository con files di sole dipendenze (una specie di slack-required distinto dal pacchetto).

M

[amn]

ah! in effetti credo che amn parlasse di realizzare un repository con files di sole dipendenze (una specie di slack-required distinto dal pacchetto).

M

Si esatto, comunque ora sto vedendo un po`..

[sunreal]

Che su slackware manchi un package manager è chiaro come il sole, e che gli attuali strumenti disponibili, swaret, slapt-get, etc, non sono il massimo altrettanto, quindi benvenga un qualsiasi tentativo di migliorare le cose, io vorrei dire alcune cose anche se forse sono sciocchezze, visto che io sto all'informatica come un pinguino all'equatore, quindi abbiate pazienza,
--->non si potrebbe inserire un opzione che faccia scegliere tra compilazione automatica e compilazione passo passo scegliendo tra le varie opzioni di config?
--->da quello che ho letto mi sembra che bisogna in qualche modo inserire nei pacchetti un qualcosa che comunichi le dipendenze al package manager, quindi gli attuali pacchetti di slacky non vanno bene, e se invece si crea una specie di "albero delle dipendenze" che il packager consulta prima di installare i pacchetti relativi così il repository di slacky sarebbe ok e per cominciare non è niente male, chi cerca software aggiuntivi per adesso si arrangia
--->credo che se questo progetto serva per aumentare la "clientela" di slackware non si debba prescindere da una gui
Se questo progetto va in porto e ci fosse bisogno di un paio di braccia, non di una mente informatica, io sono disponibile. Ciao.

[Luke88]

l'idea mi piace, posso dire la mia anche io?

--->non si potrebbe inserire un opzione che faccia scegliere tra compilazione automatica e compilazione passo passo scegliendo tra le varie opzioni di config?

perchè no... qualcosa dello stile pkgtool però. il tutto deve essere usabile da console. comunque in questo caso lo lascerei come opzione, magari nel file di config.

--->da quello che ho letto mi sembra che bisogna in qualche modo inserire nei pacchetti un qualcosa che comunichi le dipendenze al package manager, quindi gli attuali pacchetti di slacky non vanno bene, e se invece si crea una specie di "albero delle dipendenze" che il packager consulta prima di installare i pacchetti relativi così il repository di slacky sarebbe ok e per cominciare non è niente male, chi cerca software aggiuntivi per adesso si arrangia

e in ibrido? cioè.. se nel pacchetto non c'è lo slack-required, allora cerca le dipendenze, e altrimenti arrangiati? servirebbe qualcosina di più veloce e più chiacchierone di swaret -1.6.2...

--->credo che se questo progetto serva per aumentare la "clientela" di slackware non si debba prescindere da una gui
Se questo progetto va in porto e ci fosse bisogno di un paio di braccia, non di una mente informatica, io sono disponibile. Ciao.

io resto sul fatto che deve essere usabile da console.
poi si possono sviluppare le gui, che si appoggierebbero al programma principale... se si vuole fare un (bel) po' di lavoro in più, si può realizzare 2 gui, una in gtk e l'altra in qt, magari simili, così accontentiamo tutti , però per me resta un lavoro molto secondario.

io ci metterei la possibilità di ricompilazione, in 4 metodi:
1- pacchetto presente in repos con sorgenti& slackbuild. prendere e ottimizzare (dati forniti nel file di config) in automatico.
2- vedi punto uno, ma ricompilazione con possibile modifica di flags e/o .configure, tramite scelta di opzioni tratte da "./configure --help"
3-compilazione di pacchetto non presente in repos: il pacchetto viene scaricato o è in una dir: viene creato un tgz da uno slackbuild standard a cui vengono modificati nome/arch/flag/build, il ./configure non avrebbe opzioni.
4- vedi pt 4, ma opzionalmente si abilitano flags e/o opzioni ./configure da un elenco preso da "./configure --help" (il menu può essere -a scelta utente- un elenco su console o un menu di selezione tipo pkgtool.)

il pt.3 in automatico è utile a chi serve urgentemente un pacchetto e non vuole perdere tempo e contemporaneamente averlo disponibile tramite pkgtool.

ovviamente ogni opzione presente nel file di config dovrebbe poter essere cambiata dalla riga di comando, temporaneamente.



il problema della modifica dello slackbuild per me è abbastanza rilevante e può essere risolto introducendo uno slackbuild standard, che comprende ogni opzione disponibile, da proporre come standard a pat e e chiunque, e comunque introdurre un modo per modificare slackbuild non standard (con warning), anche se questo comporterebbe l'avere uno slackbuild non troppo pulito.
penso sia leggermente più facile di quello che può sembrare. non è impossibile. in caso di fallimento buttiamoci comunque un "arrangiati"
Ci stavo già lavorando un paio di settimane fa ma ora ho troppi impegni e il tutto mi è restato all'inizio... avrei uno script che lavora alla ricompilazione di un repository, locale o remoto, ma manca un po' troppa roba ovviamente non è funzionante... se lo volete... ma non isultatemi per quello, so benissimo che così com'è c'è tanto da modificare.



ultima cosa da sviluppare (ma prima della gui) per me sarebbe un tool sempre stile pkgtool per scrivere il file di configurazione.


se cominciate subito non vi posso dare una mano in questo mese, sono troppo inpegnato, ma da ottobre non dovrei avere problemi e avrete sicuramente la mia collaborazione

[Luke88]

dimenticavo...

un altro problema della ricompilazione sarebbe che non esiste solo "make"...
bisognerebbe fare la stessa cosa per scons, perl e almeno i più diffusi metodi di ricompilazione...

[sir_alex]

Salve a tutti,
riporto una frase scritta da Sawk in questo topic: Slackware? Perchè?

slackware l'unica cosa a cui manca è un tool di gestione personale che gestisca facilmente le dipendenze e possa combattere contro emerge o apt-get

Discutiamo un attimo su questo argomento perfavore.
Voi sareste felici se qualcuno creasse un gestore di pacchetti per slackware che risolva dipendenze, del calibro di apt o di emerge?
A me non darebbe fastidio alla fine, se uno non vorrebbe usarlo, nessuno gli vieterebbe di non usufruirne.
Secondo me sarebbe una buona cosa, perche` molte persone (e non parlo solo di quelli che non usano slackware
perche` non hanno un package manager della portata di apt o di emerge) sarebbero ben felici e, si troverebbero molto comode,
usando Slackware, in tutta la sua pulizia e in tutta la sua stabilita`, con un gestore di pacchetti scritto come si deve,
che controllerebbe, su richiesta dell'utente, le dipendenze del pacchetto e le installerebbe.
Pulito, leggero, e che non "sporchi" slackware, da farla rimanere una distribuzione pulitissima come se si installassero
solo pacchetti per slackware con installpkg, ma rendendo il tutto un po' piu` comodo.

Voi cosa ne pensate?
La vostra opinione mi interessa molto.

Inanzitutto apt-get non risolve le dipendeze,quindi un gestore come quello meglio perderlo che trovarlo

Non risolve le dipendenze? Ma hai mai usato una debian in vita tua? Apt-get esiste apposta perchè risolve le dipendenze...

[conqueror]

ragazzi vi dico anche la mia. Il tool in questione dovrebbe mantenere la filosofia slackware, cioè fare tutto noi, dipendenze (risolvendole lui naturalmente) etc... Mi spiego meglio, sul portatile ho messo gentoo (perchè mi offriva un ottimizzazione per l'amd64), però da buon slackwarista non digerisco a pieno emerge (che è potentissimo, ma secondo me si impossessa del sistema). Non so quanti di voi conoscano il sistema di gentoo del portage e di emerge. In pratica tutto è mirato all'ottimizzazione, e quindi alla compilazione di tutti i pacchetti, nel momento in cui però viene a incepparsi un qualcosa durante un installazione ecco lì che è finita (oppure se capitano pacchetti mascherati etc....). In questo caso o si aspetta una nuova release e ti metti a fare a santa e sacra manina come ci insegna La Distribuzione (Slackware naturalmente).
Proprio questo è capitato a me con eclipse è il jdk, che chissà per quale assurdo motivo è mascherato per l'architettura amd64 (però come ho fatto io a manina funziona perfettamente). insomma avevo bisogno di eclipse, e non me lo installava neanche smascherandolo, idem per il jdk, allora ho installato tutto a mano (e funziona alla grande, anche con il cdt su eclipse). L'altro giorno volevo mettere azureus, che come dipendenza ha il java, e emerge indovinate un pò, non trova java perchè naturalmente io l'ho messo da solo (con tutti i java-config etc...).
Il succo di tutto questo è che un tool per i pacchetti slack dovrebbe tener traccia di tutti (tutti) i pacchetti, anche quelli installati a mano, e anche di quelli installati senza i pacchetti cioè installati compilandoli (il fatidico make install lol), senza impossessarsi del sistema, deve essere solo un aiuto e non come in gentoo (però gentoo è stata concepita così, quindi non è un rimprovero questo) un Sistema di gestione quasi totale.

Comunque sono uno studente di ingegneria informatica, se posso essere d'aiuto lo faccio molto volentieri.

[amn]

--->non si potrebbe inserire un opzione che faccia scegliere tra compilazione automatica e compilazione passo passo scegliendo tra le varie opzioni di config?

sicuramente.

Tornando a noi.. allora, ieri pomeriggio mi son svegliato e mi e` venuta una strana idea.
Allora io volevo fare una cosa tipo "emerge" di Gentoo Linux.
La mia idea era:
mettere a disposizione degli specie di ebuild (chi conosce Gentoo sa come funziona),
dove per ogni pacchetto c'e` scritto versione, descrizione, dipendenze etc.
Il tool per prima cosa andrebbe ad analizzare l'ebuild prendendone tutte le informazioni.
Dopodiche` (oltre alla la possibilita` di compilazione manuale), riguardo i precompilati per slackware,
pensavo di indirizzare il tool su mirror ufficiali (vedi slackware.it).
Scarica il pacchetto, tutte le dipendenze (calcolate nell'analizzazione dell'ebuild) dopodiche` installa il tutto con installpkg.
Si potrebbe anche potenziarlo di modo che tenga traccia di tutte le cose installate (ovviamente tramite il tool),
per poi, quando si rimuove un pacchetto, di (decisione dell'utente) rimuovere anche tutte le dipendenze del pacchetto.
Questa sarebbe l'idea di base, da ampliare\criticare\distruggere\sotterrare.
Pensavo a questo perche` mi ha colpito molto il sistema emerge/portage di Gentoo.

Ditemi voi cosa ne pensate.

[Luke88]

absinthe, correggimi, ma non è quello che fa il tuo tool, tracepkg?
in effetti la cosa è interessante, e io direi di integrarlo...

a dire il vero non ho capito molto in cosa si differenzierebbe il metodo di amn dall'usare i tgz esistendi sfruttando gli slack-desk. a parte il dovere prendere le cose da 2 parti (come amn?) o da 1(slack-desk).
confesso in effetti che non conosco gentoo...

io sarei per la creazione di meno cose nuove possibili, per cui direi di usare i repos sia per i sorgenti (slackbuild, slack-desk, *.tar.gz) e anche per le dipendenze (slack-required).

al massimo per le dipendenze possiamo fare una cosa tipo "se non c'è slack-required, fallback su repos tipo swaret".

[amn]

http://www.gentoo.org/doc/it/handbook/h ... t=2&chap=1
Guarda li`, per farti capire..
volevo fare una cosa simile, introdurre gli ebuild anche in slackware,
ovviamente modificati. Comunque ti lascio leggere che ti spiega bene

[absinthe]

absinthe, correggimi, ma non è quello che fa il tuo tool, tracepkg?
in effetti la cosa è interessante, e io direi di integrarlo...

dunque, al momento tracepkg funziona solo con i compilati (non con gli interpretati) e si occupa di cercare tutte le dipendenze di un tgz controllando se sono installate o meno. _NON_ controlla se la versione è corretta e , in caso di pacchetti mancanti, _NON_ è in grado di trovarli da solo: può solo dirti (tramite ldd) quale file manca, poi te lo devi cercare da solo in una filelist tipo il manifest.bz (funzione che verrà implementata nella v.1.01 se riuscirò mai a terminare i test della 1.0 :P).
se facessimo come dice amn a quel punto avremmo dei file ascii dove sono indicati _TUTTI_ i tgz delle dipendenze, sia installati che mancanti. a quel punto con una rapida verifica in /var/log/pakages un qualsiasi script/applicativo capirebbe cosa è installato e cosa manca... a quel punto però sarebbe utile gestire il tutto in stile apt-get (slapt-get) tenendo in conto anche della versione della dipendenza con cui è-stato-compilato/deve-essere-compilato un binario.

M

[absinthe]

a dire il vero non ho capito molto in cosa si differenzierebbe il metodo di amn dall'usare i tgz esistendi sfruttando gli slack-desk. a parte il dovere prendere le cose da 2 parti (come amn?) o da 1(slack-desk).

in nulla tranne nel fatto che se hai 2 repository distinti per tgz e slack-required (chiamiamoli così) c'è un rischio maggiore di "asincronia" tra i 2 servers... ma se gestisci tutto a livello di singolo build versione e pacchetto non ci sono problemi. al più il tool ti direbbe: " vacca boia! non ho il file per le dipendenze, devi arrangiarti!"

io sarei per la creazione di meno cose nuove possibili

concordo.

M