slacky.eu

slacky.eu offre l'ottimo servizio dei pacchetti precompilati ... però ne mancano tantissimi, in particolare nei repository più recenti ... chiaro, per farli ci si perde un sacco di tempo ... e comunque, giustamente, devono essere avallati da Loris (o da qualcuno dello staff) ...

propongo quindi (se è lecito farlo, ma credo di sì), di caricare nel repository anche pacchetti con slackbuild "semi-integrale" di SBo, con la semplice aggiunta del requirebuilder: ... a questi pacchetti si potrebbe dare l'estensione SBoSl, mantenendo il nome e copyright degli sviluppatori originali ... sarebbero pacchetti SBo originali ai quali è stata applicato il codice di cui sopra ...

Non so,non è un po' come "rinnegare" quello che è stato il punto di forza di slacky.eu (il repository)?

Vito ha scritto:Non so,non è un po' come "rinnegare" quello che è stato il punto di forza di slacky.eu (il repository)?

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 ...

Sono daccordo con zoros bisognerebbe aggiungere un repo di terze parti ed accentrare tutto sotto slacky.eu

ha ragione zoros mi sembra che il lavoro di packager stia un po sparendo.....ma c'e' arch... vuoi mettere.

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.

in quanto packager a 64bit, a me personalmente, farebbe comodo invece un sistema di segnalazione di nuovo software da pacchettizzare/lacuna da colmare, perchè nel mio caso è questa parte del 'lavoro' che paradossalmente porta via del tempo. infatti una volta creati i pacchetti piu' blasonati.. ammetto di andare un po' a briglie sciolte

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

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. ...

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) ...

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

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 ...

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 ...

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.
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

conraid ha scritto:a il problema originario rimane immutato

quello che secondo me in un certo senso sta dicendo conraid è che c'e' una sola vera spiegazione possibile.. siamo in pochi a pacchettizzare

quello che piu' o meno volevo dire io è che pacchettizzo perchè credo sia giusto contribuire, ma a parte i pacchetti che uso direttamente e qualcun'altro che reputo principale ci metterò un po' a pacchettizzare lo strano lettore multimediale da console che non conosco(limite mio dovuto anche al tempo che dedico a questa attività).

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) ...

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.

conraid ha scritto:

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 ...

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.
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 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 ...

secondo me si perde un sacco di tempo a rivedere la struttura dello slackbuid ... se mi sono fatto un t*z da SBo e mi funziona lo manderei subito sul repository senza troppe pretese (di affidabilità, intendo) ...

miklos ha scritto:...

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) ...

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.

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 ...

provo a farti un esempio chiarificatore del mio punto di vista

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 ...

vorrei pacchettizzarlo(a 64bit) prendendo spunto da un altro tuo post:

1- tempo per fare gli slackbuilds (15-20 minuti se sono abbastanza standard)
2- tempo di compilazione (manco troppo)
3- tempo per venirne a conoscenza (una vita)

è il punto 3 che, come ho provato a spiegarti prima, rallenta un po' le cose, perchè magari avrei dato piu' "importanza" ad altro.
tutti i packager dell'universo (esclusi quelli stipendiati per farlo) pacchettizzano software che conoscono e utilizzano nel quotidiano.
il fatto che altre distribuzioni hanno repository gonfi è perchè aime' di pacchettizzatori ne stanno molti di piu'... quindi per la legge dei grandi numeri è piu' facile che qualcuno usi quel dato software.

ma è grazie alla tua segnalazione (come tempo fa è successo pure per ktsuss) che alla fine è piu' facile per chi pacchettizza darsi delle 'priorita' nel tentativo di rendere il repository sempre migliore

sì, miklos,
le tue considerazioni sono valide ... ma, sempre come esempio, i pacchetti di cui sopra sono presenti nei vecchi repository, ma mancano nei nuovi ... segno che per correre dietro alle continue novità (e all'aumentare del numero di pacchetti) poi non si trova il tempo per tenere aggiornato il repository anche su librerie ancora attuali ... per questo dico che se slacky.eu potesse avere anche un ramo "unofficial" = sbrigativo e senza pretese, forse il tempo si potrebbe trovare ...

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.

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.

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 ...

comunque non so come sia gestito/strutturato il repository, però per i pacchetti mancanti mi aspettavo di trovare almeno lo spazio per accoglierli, esempio:

http://repository.slacky.eu/slackware-1 ... pcsc-lite/ c'è il pacchetto (datato, ovviamente)
http://repository.slacky.eu/slackware-1 ... pcsc-lite/ non c'è neanche lo spazio per accoglierlo