Moderatore: Staff
Codice: Seleziona tutto
if [ -x /usr/bin/requiredbuilder ];then
requiredbuilder -y -v -c -b -s $CWD $PKG
fi
la mia proposta sarebbe di tenere nel repository anche dei pacchetti "testing", presi da SBo ad esempio, ai quali si potrebbe applicare il suffisso SBoSl in attesa di completare e approvare lo slackbuild ...Vito ha scritto:Non so,non è un po' come "rinnegare" quello che è stato il punto di forza di slacky.eu (il repository)?
sicuramente slacky.eu è un bel repository, io uso slackyd per arricchire la mia Slack, è configurato per "pescare" dalla 13.37 fino alla 12.2 ... ti assicuro che molti pacchetti mancano (e li ritrova solo nei vecchi repository) ...miklos ha scritto:fare uno slackbuild, se si è pratici non è roba che porta via troppo tempo (esclusi casi particolari) e slacky (almeno il repo a 32bit) è piu' grosso di tanti repository terzi. ...
conraid ha scritto:Non faccio pacchetti per slacky da molto tempo, non avendo una stable e seguendo (anche quello in modo minore rispetto a mesi fa, slackers.it), ma non ho ho capito il problema
I pacchetti SBo sono liberi, quindi basta prenderli e cambiare qualcosa. Si possono liberamente usare per creare pacchetti.
Il problema è proprio che una volta creato il pacchetto questo deve essere inserito nel repository da Loris, in modo che poi vengano creati tutti i file necessari al repository. Il seguire il template è solo una indicazione, niente vieta di usare quelli di SBo con l'aggiunta e/o la modifica di qualcosa. Ma il problema originario rimane immutato
... i miei sono per -current (e non hanno slack-required per scelta), quelli di SBo non sono pacchetti, ma solamente slackbuild, quindi vanno pur sempre compilati ed impacchettati. Io non ci vedo tutta questa differenza.zoros ha scritto: non so bene come è organizzato il lavoro del repository, secondo me aggiungere pacchetti di terza parti, con la sola modifica dello slackrequired, potrebbe alleggerire il lavoro (e darci un servizio rapido) ... potremmo anche trovare i tuoi pacchetti (non standard, ma molto probabilmente compatibili) con suffisso cfSl
quello che secondo me in un certo senso sta dicendo conraid è che c'e' una sola vera spiegazione possibile.. siamo in pochi a pacchettizzareconraid ha scritto:a il problema originario rimane immutato
perdonami ma i pacchetti che si possono trovare e che per esempio sono per kde 3.5, o che magari non piu' sviluppati e quindi non compilabili, oppure ancora sono passati nella stable ti danno stime un po' fasulle.zoros ha scritto:sicuramente slacky.eu è un bel repository, io uso slackyd per arricchire la mia Slack, è configurato per "pescare" dalla 13.37 fino alla 12.2 ... ti assicuro che molti pacchetti mancano (e li ritrova solo nei vecchi repository) ...
mi sembrava chiara la proposta: prendere degli slackbuild da SBo, oppure da slackers.it, così come sono ... quindi applicare allo script le istruzioni per lo slackrequired, compilare il tutto, inserendoli nel repository come -SBoSl, o -cfSl mantenendo struttura e copyright (autore intendo) ... chi scarica saprà che sono pacchetti di terze parti adattati a slacky.eu al solo scopo di fornire un t*z binario ... quindi anche i tuoi -current andrebbero ricompilati ...conraid ha scritto:i miei sono per -current (e non hanno slack-required per scelta), quelli di SBo non sono pacchetti, ma solamente slackbuild, quindi vanno pur sempre compilati ed impacchettati. Io non ci vedo tutta questa differenza.zoros ha scritto: non so bene come è organizzato il lavoro del repository, secondo me aggiungere pacchetti di terza parti, con la sola modifica dello slackrequired, potrebbe alleggerire il lavoro (e darci un servizio rapido) ... potremmo anche trovare i tuoi pacchetti (non standard, ma molto probabilmente compatibili) con suffisso cfSl
Per il repository ogni volta che viene aggiunto un pacchetto va lanciato uno script che crea i file PACKAGES, FILELIST, etc..., non si può mettere un pacchetto in una directory e basta, altrimenti slackyd per esempio non lo vede
mi riferisco a programmi "indipendenti" dal DM e librerie generiche ... mancano anche tanti pacchetti generici ... ad esempio per la CNS (carta dei servizi per comunicare con la PA) mi servivano 4 librerie generiche ... neanche una sul repository 13.37 ...miklos ha scritto:...perdonami ma i pacchetti che si possono trovare e che per esempio sono per kde 3.5, o che magari non piu' sviluppati e quindi non compilabili, oppure ancora sono passati nella stable ti danno stime un po' fasulle.zoros ha scritto:sicuramente slacky.eu è un bel repository, io uso slackyd per arricchire la mia Slack, è configurato per "pescare" dalla 13.37 fino alla 12.2 ... ti assicuro che molti pacchetti mancano (e li ritrova solo nei vecchi repository) ...
vorrei pacchettizzarlo(a 64bit) prendendo spunto da un altro tuo post:zoros ha scritto:ad esempio per la CNS (carta dei servizi per comunicare con la PA) mi servivano 4 librerie generiche ... neanche una sul repository 13.37 ...
in realtà non parlavo di un repo "unofficial", ma di far posto nel repo ufficiale a pacchetti non ancora ben testati, i quali avrebbero un suffisso diverso da "-sl" ... chi scarica sa di scaricare qualcosa di "unofficial slacky.eu" ... l'alternativa per chi non trova il pacchetto x e non sa farselo (o non ha tempo, ecc.) è di finire per scaricarlo da siti ancora meno affidabili ...Loris ha scritto:Ma se facciamo un repo unofficial, poi, chi lo aggiorna? chi lo popola? i pochi pacchettizzatori che lavorano per noi non possono prendersi altro lavoro.
:cf