Perché fate i pacchetti e non usiamo slackbuild.org?

[lablinux]

E' solo una curiosità e non una provocazione.
Mi affascina l'idea di pacchettizzare, quando mi avanzano un paio d'ore vedo se sono in grado di farne uno di prova.

Ci sono ideologie differenti tra slackbuild.org e slacky.eu?
Si pacchettizza diversamente? Una risposta fu "le dipendenze".

Ciao e grazie delle risposte e dei pacchetti.

[hashbang]

Slackbuilds.org è un repository dove non si distribuiscono pacchetti, ma bensì SlackBuild, slack-desc e tutto il necessario per la creazione di un pacchetto. Può definirsi come un sistema di Port, per dirla alla *BSD. Slacky.eu fornisce un repository di precompilati.

Inoltre abbiamo modi diversi di scrivere gli script di compilazione:
Noi utilizziamo architetture predefinite, mentre SlackBuilds.org sfrutta lo uname -m per ricavarla. E infine i loro SlackBuild, per questione di portabilità, creano pacchetti tgz; noi seguiamo lo standard di Slackware. Infatti dalla 13.0 si pacchettizza in txz. Ovviamente nel loro caso basta dare un export e si ottiene lo stesso risultato.
Per quanto riguarda le dipendenze è una conseguenza della nostra diversità e non la causa. Noi siamo "fissati" per le dipendenze in quanto noi pacchettizziamo. Loro scrivono solo SlackBuild e quindi non si preoccupano affatto se tutte le dipendenze sono disponibili. Inoltre, proprio per il fatto che noi dobbiamo creare pacchetti utilizziamo requiredbuilder per stampare le dipendenze esatte del pacchetto. Infatti la nostra caratteristica è di pacchettizzare su una Slackware stable full e pulita, mentre per SlackBuilds.org si può pure usare una -current "sporca", tanto non si deve creare il pacchetto ma bensì lo SlackBuild.

Quello che io ammiro di SlackBuilds.org è che gli SlackBuild sono aderenti ai loro standard. Tutti sono scritti alla stessa maniera, dando uniformità al repository.

[simplex]

S Inoltre, proprio per il fatto che noi dobbiamo creare pacchetti utilizziamo requiredbuilder per stampare le dipendenze esatte del pacchetto.

Su questo non sono d'accordo. Le dipendenze di un pacchetto vanno stabilite leggendo la doc del software, requirebuilder non e' uno strumento preciso.

[ponce]

atomix, un paio di precisazioni:
- tutti gli slackbuild di slackbuilds.org hanno indicate le dipendenze nel README e vengono inclusi anche gli slackbuilds di queste.
- tutti gli script sono testati, ci viene fatto il pacchetto e viene usato, non solo da chi li invia, ma anche dagli stessi maintainers di slackbuilds.org.

requiredbuilder ti indica le dipendenze del pacchetto ormai gia' compilato (usa ldd per vedere a cosa si e' linkato), concordo con simplex che la documentazione dei sorgenti sia insostituibile come affidabilita').

[hashbang]

S Inoltre, proprio per il fatto che noi dobbiamo creare pacchetti utilizziamo requiredbuilder per stampare le dipendenze esatte del pacchetto.

Su questo non sono d'accordo. Le dipendenze di un pacchetto vanno stabilite leggendo la doc del software, requirebuilder non e' uno strumento preciso.

Quando le dipendenze non vengono specificate interveniamo noi con gli ADD manuali. In ogni caso lo slack-required è un ottimo riferimento.

EDIT per ponce (ho visto solo ora la tua risposta): il mio intento non è quello di declassificare SBo, anzi (uso anche io il loro repository). Solo che abbiamo due mentalità differenti di distribuzioni degli applicativi. Ovviamente gli SlackBuild sono testati, ci mancherebbe. Non ho mai detto che loro non li testano. Dico solo che ciò che ci caratterizza non sono le dipendenze in se per se, ma è la modalità di distribuzione. port da una parte e precompilati dall'altra.

Per quanto riguarda la documentazione stesso discorso. La documentazione nei sorgenti è importante, nessuno lo mette in dubbio. Requiredbuilder spiegavo all'autore che è un tool che ci caratterizza in quanto lo usiamo mettere all'interno degli SlackBuild per evidenziare le dipendenze del pacchetto.

[albatrosla]

- tutti gli slackbuild di slackbuilds.org hanno indicate le dipendenze nel README e vengono inclusi anche gli slackbuilds di queste.
[...]requiredbuilder ti indica le dipendenze del pacchetto ormai gia' compilato (usa ldd per vedere a cosa si e' linkato), concordo con simplex che la documentazione dei sorgenti sia insostituibile come affidabilita'.

Anche qui le dipendenze sono tutte elencate, nello slack-required. required-builder è abbastanza affidabile; dove non gliela fa, sopperisce il packager.

- tutti gli script sono testati, ci viene fatto il pacchetto e viene usato, non solo da chi li invia, ma anche dagli stessi maintainers di slackbuilds.org.

Anche su slacky è così. Testo sempre i package che produco, così verifico le dipendenze ed il funzionamento. Oltre a ciò, prima che venga pubblicato, il pacchetto viene verificato anche da alcuni membri dello staff.

E' un sistema infallibile? Probabilmente no, ma è più che soddisfacente e siamo sempre attenti ai feedback degli utenti.
Anche qui si è stabilita una metodologia standard per scrivere gli slackbuild. Tutti quelli prodotti per la 13.1 sono stati riscritti in quest'ottica e siamo fiduciosi di arrivare ad un repository abbastanza standardizzato (tuttavia, alle volte sono gli stessi sorgenti che richiedono approcci fuori standard).

Per rispondere alle domande che hanno aperto questo thread: la particolare ragion d'essere di un repository piuttosto che di un archivio di slackbuild risiede nella facilità con la quale gli utenti installano il software precompilato. Un utente, specie se alle prime armi, difficilmente affronta una compilazione anche se si tratta solo di lanciare uno script. Penso che questa sia la caratteristica peculiare di un sito come questo e in un qual modo anche la sua filosofia. Il modo in cui si scrive uno slackbuild, invece, è qualcosa che dipende molto dal gusto personale di chi ha dato l'impronta allo standard: è ciò che accade, in fin dei conti, in qualsiasi codice.

[lablinux]

Quindi siamo (scusate se mi includo) più vicini a linuxpakages.net? Anche se loro sono rimasti un po in dietro (manca l'architettura 64 bit),

Grazie a tutti per le delucidazioni.

[ZeroUno]

Quindi siamo (scusate se mi includo) più vicini a linuxpakages.net?

No.
Loro (almeno fino all'ultima volta che ho scaricato un loro pacchetto, e risale a diverso tempo fa) non forniscono lo slackbuild. In questo modo non c'è trasparenza sulla compilazione. Se non erro si affidavano parecchio ai tool quali checkinstall&co

Anche se loro sono rimasti un po in dietro (manca l'architettura 64 bit)

Più che indietro direi che il 13.1 è inesistente... a parte il 64bit, il 32 ha solo 26 pacchetti.

Package How-To:

Building a Slackware Package
Updated 25 April 04

[ildiama]

Scusate, mi dispiace intromettermi "in gamba tesa", però le differenze tra slacky e SBo non sono e non possono ridursi alla comodità del pacchetto precompilato vs la pulizia dello slackbuild preconfezionato.
Gli slackbuild (e quindi i pacchetti) di SBo seguono a pieno la filosofia slackware. E infatti molto spesso passano da SBo alla slackware official. Gli slackbuild e i pacchetti di slacky no, non sarebbero mai inclusi da Pat, perché sono "fatti male".
Però diciamo pure che la competenza/esperienza di molti pacchettizzatori e i test continui a cui gli utenti di slacky sottopongono continuamente i pacchetti fanno sì che la qualità di questi sia comunque molto elevata.

[joe]

Non tutti i sistemi sono installati full e potrebbe darsi che non siano installati tools di sviluppo per compilare cosicchè lo slackbuild non fingue, ma il pacchetto precompilato viene installato e gira regolarmente. Anche questo potrebbe essere uno dei tanti motivi per mettere a disposizione un repo come slacky.eu.
Detto ciò in ogni caso vi sono le dir "src" che comprendono lo slackbuild e tutto l'occorrente per pacchettizzarsi il software autonomamente.

[hashbang]

Gli slackbuild (e quindi i pacchetti) di SBo seguono a pieno la filosofia slackware. E infatti molto spesso passano da SBo alla slackware official. Gli slackbuild e i pacchetti di slacky no, non sarebbero mai inclusi da Pat, perché sono "fatti male".
Però diciamo pure che la competenza/esperienza di molti pacchettizzatori e i test continui a cui gli utenti di slacky sottopongono continuamente i pacchetti fanno sì che la qualità di questi sia comunque molto elevata.

Perdonami, ma non ho capito quel "sono fatti male"
Noi pacchettizziamo su una Slackware Stable Full e Pulita. Lo staff controlla il pacchetto e lo slack-required. Provvediamo sempre a riportare la Slackware usata per i pacchetti allo stato originale dopo le compilazioni. IMHO non mi pare siano fatti male, anzi sono fatti in modo impeccabile.

E se devo dirla tutta sinceramente preferisco i nostri SlackBuild per due motivi:
1) Non mi piace il loro modo di gestire le architetture. Chiamare in causa lo uname -m per ricavare l'architettura non è IMHO una buona cosa. Se è parlato tanto quì, visto che c'è chi voleva la stessa gestione.

2) La loro gestione dei permessi è IHMO molto più inutilmente incasinata.
Il loro metodo:

Codice: Seleziona tutto

find . \
 \( -perm 777 -o -perm 775 -o -perm 711 -o -perm 555 -o -perm 511 \) \
 -exec chmod 755 {} \; -o \
 \( -perm 666 -o -perm 664 -o -perm 600 -o -perm 444 -o -perm 440 -o -perm 400 \) \
 -exec chmod 644 {} \; || exit 1

Il nostro:

Codice: Seleziona tutto

chmod -R u+x,go+r-w,a-s .

[notsafe]

]Perdonami, ma non ho capito quel "sono fatti male"

nei pacchetti "slacky.eu" sono inseriti i campi:

Codice: Seleziona tutto

PACKAGE REQUIRED:
PACKAGE CONFLICTS: 
PACKAGE SUGGESTS: 


campi che non li rendono "filosoficamente slackware" (sia chiaro che non voglio aprire polemiche)

[albatrosla]

Il termine "fatti male" è troppo vago, visto che - come dicevo - il modo in cui scrive un codice è in buona misura soggettivo, e perciò al di là di alcune basi non si può dire "giusto" o "sbagliato", "bene" o "male", parlando di un modus piuttosto che di un altro. Io direi piuttosto che sono fatti in modo semplice, e pertanto comprensibile ai più.
Dire che le dipendenze non sono nello stile e nella filosofia slackware è errato. Il fatto che la slackware non preveda tool ufficiali che risolvano le dipendenze, e pacchetti strutturati in modo da tracciarle, non significa che questo sia giusto o sbagliato secondo la sua filosofia. Faccio un esempio: con slackyd, scaricando un package da slacky si ottiene anche la richiesta di download per tutte le dipendenze del tal package. Non si è in nessun modo costretti ad accettarne il download, e l'installazione è comunque a carico dell'utente. Ciò significa che slackyd lascia totale libertà all'utente di operare nell'upgrade/installazione dei pacchetti, i quali dispongono delle informazioni necessarie a farlo funzionare. Ciò non rende slackyd un tool ufficiale, non lo rende incompatibile né con il sistema né con la filosofia della distro, e - nondimeno - non rende incompatibili i pacchetti con la filosofia slackware. Non credo che il mantainer (PJV) aborri l'uso di tool come slackyd, per quanto non li includa nella distribuzione ufficiale. Non dimentichiamo che slackpkg fa praticamente la stessa cosa (anche se non verifica le dipendenze) e si occupa addirittura di eseguire l'installazione automaticamente. Sicuramente, in un'ottica di robustezza, l'installazione è qualcosa di più delicato rispetto al download delle dipendenze; tuttavia nessuno si sogna di dire che slackpkg sia un tool non in linea con la filosofia della distribuzione.
In sintesi, i nostri package includono informazioni in forma tale da poter conoscere le dipendenze per scaricarle/installarle con tool appositi, oppure per replicare il package stesso. Non è questa maggiore informazione a rendere il pacchetto indigesto allo slackwarearo duro e puro, casomai è l'uso che se ne fa. D'altro canto pure PJV consiglia un uso prudente e consapevole di slackpkg.

[hashbang]

D'accordissimo con albatrosla

nei pacchetti "slacky.eu" sono inseriti i campi:

Codice: Seleziona tutto

PACKAGE REQUIRED:
PACKAGE CONFLICTS: 
PACKAGE SUGGESTS: 


campi che non li rendono "filosoficamente slackware"

Veramente quei campi non fanno parte dei pacchetti di Slacky.eu, ma fanno parte del file PACKAGES.TXT presente nel repository. E non credo che a Pat importi se nel nostro repository, per comodità, abbiamo aggiunto quelle diciture che, oltretutto, non influenzano minimamente il pacchetto. Anche perchè il file PACKAGES.TXT presente nei mirror ufficiali di Slackware viene scritto da lui stesso, quindi non gliene può fregar di meno se noi usiamo fare così. Inoltre non credo che Pat, nonostante preferisca gli SlackBuild di SBo (ed è comunque una affermazione che lascia il tempo che trova visto che non è stata riportata nemmeno una fonte, a meno che non siate in stretto contatto con lui), "ricicli" gli SlackBuild dei pacchetti che ha deciso di integrare nella distribuzione. Penso che li riscriva secondo le sue esigenze e metodi di pacchettizzazione.

[notsafe]

Dire che le dipendenze non sono nello stile e nella filosofia slackware è errato. Il fatto che la slackware non preveda tool ufficiali che risolvano le dipendenze, e pacchetti strutturati in modo da tracciarle, non significa che questo sia giusto o sbagliato secondo la sua filosofia. Faccio un esempio: con slackyd, scaricando un package da slacky si ottiene anche la richiesta di download per tutte le dipendenze del tal package. Non si è in nessun modo costretti ad accettarne il download, e l'installazione è comunque a carico dell'utente. Ciò significa che slackyd lascia totale libertà all'utente di operare nell'upgrade/installazione dei pacchetti, i quali dispongono delle informazioni necessarie a farlo funzionare. Ciò non rende slackyd un tool ufficiale, non lo rende incompatibile né con il sistema né con la filosofia della distro, e - nondimeno - non rende incompatibili i pacchetti con la filosofia slackware. Non credo che il mantainer (PJV) aborri l'uso di tool come slackyd, per quanto non li includa nella distribuzione ufficiale. Non dimentichiamo che slackpkg fa praticamente la stessa cosa (anche se non verifica le dipendenze) e si occupa addirittura di eseguire l'installazione automaticamente. Sicuramente, in un'ottica di robustezza, l'installazione è qualcosa di più delicato rispetto al download delle dipendenze; tuttavia nessuno si sogna di dire che slackpkg sia un tool non in linea con la filosofia della distribuzione.
In sintesi, i nostri package includono informazioni in forma tale da poter conoscere le dipendenze per scaricarle/installarle con tool appositi, oppure per replicare il package stesso. Non è questa maggiore informazione a rendere il pacchetto indigesto allo slackwarearo duro e puro, casomai è l'uso che se ne fa. D'altro canto pure PJV consiglia un uso prudente e consapevole di slackpkg.

The Slackware Philosophy

Since its first beta release in April of 1993, the Slackware Linux Project has aimed at producing the most "UNIX-like" Linux distribution out there. Slackware complies with the published Linux standards, such as the Linux File System Standard. We have always considered simplicity and stability paramount, and as a result Slackware has become one of the most popular, stable, and friendly distributions available.

http://www.slackware.com/info/

chi usa Slackware da molti anni,sa bene che uno dei punti per cui Slackware è un paradigma del genere è proprio perchè è "distaccato" dal ragionamento dell'"automatizazione" del sistema;non per nulla nella descrizione della distribuzione su distrowatch.com viene precisato questo:
"Slackware Linux is a highly technical, clean distribution, with only a very limited number of custom utilities. It uses a simple, text-based system installer and a comparatively primitive package management system that does not resolve software dependencies. As a result, Slackware is considered one of the cleanest and least buggy distributions available today - the lack of Slackware-specific enhancements reduces the likelihood of new bugs being introduced into the system. All configuration is done by editing text file"
Quindi,si,se dobbiamo ragionare secondo "Slackware Philosophy",l'implementazione di un sistema di risoluzione di dipendenze,anche se "blando/non intrusivo",è qualcosa di "contrario" al proprio concetto.
Che poi sia anacronistico in epoca di Ubuntu,questo è ben altro discorso.