proposta: nuovi pacchetti SBoSl ...

[Loris]

Non c'è perché nessuno ancora l'ha fatto, come dicevo prima... siamo in pochi a pacchettizzare

[Vito]

purtroppo a pacchettizzare siamo in pochi,
non sarebbe il caso di focalizzarsi sull'ingrandire il repo "ufficiale"?

[miklos]

forse secondo me stiamo facendo un po' di confusione.
zoros, non sapendo giustamente come funziona il manteniimento del repository, ha suggerito di usare slackbuilds di terze parti per velocizzare il lavoro.
peccato che il vero problema non sia tanto quello.. perchè alle volte ci sbircio pure io dentro gli slackbuilds esterni.. ma è una questione proprio di manodopera

forse se facessimo una conta di chi pacchettizza in modo piu' o meno regolare, si renderebbe conto del perchè il repo per quanto ci si impegni, necessita di tempo maggiore per raggiungere un determinato numero di pacchetti.
per questo io ho suggerito che forse un modo per rendere il servizio sempre migliore è quello di creare una sezione nel forum, o meglio ancora un form da compilare, dove si richiede un determinato pacchetto..
visto che si è sollevato il problema sono andato a farmi un giro alla 'concorrenza' e ho visto che c'e' quasi sempre un modo per richiedere pacchettizzazioni.

in questo modo noi pacchettizzatori continuiamo la normale attività, però con un occhio a quelle che sono le esigenze della comunità

[Vito]

bella idea miklos,
magari una cosa simile a pkgreports ,solo per le richieste!
Anche se effettivamente c'è una sezione del forum dove è possibile richiedere i pacchetti.

[zoros]

ho letto i vari interventi, certo, non ho ancora chiaro il lavoro che c'è sotto ... osservavo questo:

se il repository (da browser) si presenta con un filesystem, mi aspetto che ad ogni nuova release venga riprodotto il directory tree della precedente ... con tanti alloggiamenti vuoti da riempire progressivamente ... ma non è così, probabilmente per un motivo tecnico (ciò che si vede da browser è comunque "virtuale") ... però se ci fossero almeno gli spazi vuoti si potrebbero riempire prima o poi ...

quindi più che la richiesta di un pacchetto si potrebbe richiedere di creare lo spazio per ospitarlo ... se nel mentre ci mettiamo un t*z provvisorio io non ci vedrei niente di male ...

cioè: non può essere che anche le seguenti condizioni operative condizionino i tempi?

[Vito]

I pacchetti vanno compilati su macchine "pulite" senza altri pacchetti.
Il nostro problema effettivo è il numero di persone che possono mettere a disposizione una macchina (anche virtuale, io faccio così!) e del tempo per compilare/ricompilare i pacchetti.

[ZeroUno]

cioè: non può essere che anche le seguenti condizioni operative condizionino i tempi?

Eliminare queste condizioni operative equivale ad eliminare la peculiarità primaria del repository slacky: l'affidabilità! (comunque, per info, da allora sono stati fatti molti passi avanti per migliorare sia la velocità di pacchettizzazione che la qualità dei pacchetti)

Personalmente il mio calo in quantità di pacchetti è proporzionale alla distanza da stable a current.
Ultimamente ho poco tempo, ma all'uscita di una stable pacchettizzo abbastanza, sia pacchetti che uso normalmente che quelli che non uso.
Man mano che current avanza pacchettizzo sempre meno nuovi pacchetti perchè devo fare doppio lavoro: una versione per current (per me) e una versione per stable (per slacky).

Se anche utilizzassi slackbuild già fatti e testati da altri sia per current che per stable, comunque devo farmi tutto questo doppio lavoro.

Il problema di chi usa current sta, tra l'altro, anche nel fatto che più ci si discosta da stable e meno si scarica da stable (perchè si perde compatibilità)

Allora la soluzione non starebbe nell'inserire un 'unofficial' repository ma un repository per current, ma non so questo quanto sia accettabile la cosa.


Sarebbe da informarsi su che versione di slackware (stable/current) usa mediamente la gente che scarica da slacky.

Ci sono pacchetti che devono essere categoricamente su stable (squid, postfix, e tutti i programmi diretti ai server perchè è fuori standard che un sistemista installi una current sui propri server; per tali pacchetti io consentirei anche al pacchettizzatore di aggiornare i repository precedenti all'attuale stable; personalmente ho ancora un server con slackware 9 e uno con 10.2), mentre altri (quelli diretti al desktop) li farei principalmente per current.

Il rischio è che il repo stable rimanga povero. Il vantaggio è che la somma dei repository stable+current sarebbe indubbiamente più grande dell'attuale stable.

Il nostro problema effettivo è il numero di persone che possono mettere a disposizione una macchina (anche virtuale, io faccio così!) e del tempo per compilare/ricompilare i pacchetti.

Sarebbe utile che chi di noi può metta a disposizione degli altri una macchina virtuale? (ovviamente il pacchettizzatore si impegnerebbe a non abusare di tale disponibilità e si limiti a usare la macchina per pacchettizzare)

[targzeta]

...Sarebbe utile che chi di noi può metta a disposizione degli altri una macchina virtuale? (ovviamente il pacchettizzatore si impegnerebbe a non abusare di tale disponibilità e si limiti a usare la macchina per pacchettizzare)

Stavo pensando anche io ad una soluzione del genere. Anche io sono in current e non posso pacchettizzare. Potrei virtualizzare una stable...ma sul notebook non so se me la sento . L'idea comunque rimane abbastanza buona, si potrebbe addirittura pacchettizzare per 32 e 64 bit virtualizzando entrambe le stable.

Emanuele

[ZeroUno]

Potrei virtualizzare una stable...ma sul notebook non so se me la sento . L'idea comunque rimane abbastanza buona, si potrebbe addirittura pacchettizzare per 32 e 64 bit virtualizzando entrambe le stable.

Comunque la soluzione migliore per pacchettizzare rimane sempre e comunque un chroot.
Per un tempo ho avuto sia un chroot a 32bit che un chroot a 64bit. Garantisco che per oltre il 90% dei casi non si riscontrano problemi. E l'unico caso in cui si verificano (chromium), beh... boot in chroot e risolvi.
Però a quel punto dovevo pacchettizzare 3 volte (una per 64current, per me, una per stable64 e una per stable32).

[miklos]

io pacchettizzo tramite una virtualbox a 64bit... gli ho riservato 500Mb di ram e 20Gb di harddisk (me lo posso permettere ) e cosi' la posso lasciare in background a compilare senza troppi patemi, mentre faccio altro.
poi ogni volta che il repo viene aggiornato la ripulisco tramite slackpkg e vado avanti...

[lablinux]

Ecco arriva Loris con un solo messaggio e blocca la discussione. Il solito guastafeste
La mi domanda è semplice, perché prendere gli slackbuild da salckbuilds o da slackers e portarli su slacky? Solo per avere il binario? Ma per questo ci vogliono solo pochi minuti. Per essere compatibile con slackyd? Questo sarebbe un anltro punto di forza di slackyd... dargli la capacità di cercare anche i sorgenti da compilare da archivi come slackbuilds o slackers.

[miklos]

Ecco arriva Loris con un solo messaggio e blocca la discussione. Il solito guastafeste
La mi domanda è semplice, perché prendere gli slackbuild da salckbuilds o da slackers e portarli su slacky? Solo per avere il binario? Ma per questo ci vogliono solo pochi minuti. Per essere compatibile con slackyd? Questo sarebbe un anltro punto di forza di slackyd... dargli la capacità di cercare anche i sorgenti da compilare da archivi come slackbuilds o slackers.

si certo.. ma a che pro' se poi a pacchettizzare siamo in 3(numero puramente casuale)?!?!?!
mi sa che zoros ha fatto una giustissima osservazione.. pero' forse pochi hanno capito la vera realta' e il vero problema.. siccome siamo pochi a mantenere il repository il tempo che ci si mette per portarlo ad un livello almeno pari a quelli precedenti e maggiore

i suggerimenti fatti in questo post ci stanno tutti, per carità.. pero' in base alla mia esperienza dico che:

1) per come è organizzato il repository è piu' facile ripartire da zero ad ogni nuova stable perchè paradossalmente le verifiche da fare in caso contrario sarebbero piu' lunghe e quindi passibili di errori. @zoros esiste un sistema che tiene traccia di tutti i pacchetti.. i pacchetti da fare si sanno.. è solo che si procede per priorità.. per questo consigliavo di segnalare in qualche modo le esigenze
2) usare slackbuilds di terze parti puo' non essere altrettanto d'aiuto.. molti slackbuilds che guardo in giro hanno, in base al repository di appartenenza, opzioni di compilazione che non sempre sono complete/seguono la filosofia del nostro (uno su tutti opencv.. che quando lo pacchettizzai io si trovava in giro solo con supporto a versioni di ffmpeg arcaiche.. oppure webkit.. qui' noi abbiamo una versione molto piu' recente di quanto si riesca a trovare in giro)

[zoros]

ci sono stati parecchi interventi interessanti in questo thread ... mi riferisco alle considerazioni tecniche ... e mi pare siano uscite anche delle idee nuove ...

la mia proposta era più "politica" che tecnica: per me è meglio un repository "sporco" dove però trovi i pacchetti, piuttosto che non trovarli ... tecnicamente io dico che, in particolare su Slackware, ci sono ampi margini di compatibilità tra pacchetti compilati su versioni diverse ...

[hashbang]

Il nostro problema effettivo è il numero di persone che possono mettere a disposizione una macchina (anche virtuale, io faccio così!) e del tempo per compilare/ricompilare i pacchetti.

Sarebbe utile che chi di noi può metta a disposizione degli altri una macchina virtuale? (ovviamente il pacchettizzatore si impegnerebbe a non abusare di tale disponibilità e si limiti a usare la macchina per pacchettizzare)

Sarebbe un'ottima cosa.

Personalmente, stando su FreeBSD non ho più la Slackware in chroot per creare pacchetti. Infatti è da un pò che non mi dedico al repository.

Purtroppo come hanno detto Loris e gli altri, i packagers attivi sono veramente pochi. Il problema è che il lavoro di pacchettizzazione richiede troppo tempo: oltre ai pacchetti del repository immediatamente precedente (attualmente 13.1), rimangono quelli dei repository più vecchi (13.0 in giù).
Inoltre IMHO si perde troppo tempo a riadattare gli SlackBuild ai nuovi template. Secondo me, ne andrebbe scelto uno e mantenuto definitivamente.

Non è per polemica, ma IMHO si perde troppo tempo a riscrivere il tutto ogni volta.

[tom]

Ragazzi, io sono un ex pacchettizzatore di slacky (forse mi conoscete meglio col nick tasodan).
Da tempo non bazzico su questo forum perché mi sono dovuto laureare, e inoltre sono approdato alle più comode chakra e poi ad archlinux.

Diciamo che l'unico legame che mi resta con slackware è l'affezione che nutro per questa community, slacky.eu... lasciatemelo dire ragazzi, ma Pat ha fatto una distribuzione stupenda trascurando una cosa fondamentale: una community ufficiale. Per questo mancano i pacchetti, per questo manca (spesso) il supporto, per questo mancano tante cose.
Perché non c'è un forum ufficiale? Perché non c'è un 3rd-party-repository ufficiale?

Quelli di SBo sono bravi, quelli di gnomeslackbuild pure, anche noi siamo bravini. Perché tuttavia dobbiamo tutti lavorare a progetti diversi e disperderci, e addirittura "vergognarci" di scopiazzare l'un l'altro?
Questi problemi succedono perché i pochi utenti (come me e voi) che vogliono contribuire sono lasciati senza una guida.
Continuando così sarete sempre troppo pochi, e un giorno slackware sparirà.

Non sarebbe forse l'ora di far qualcosa perché Pat, invece di perder tempo su elucubrazioni filosofiche - tipo mettere pam o meno nella slack (cosa che ha creato non pochi problemi ai pacchettizzatori) - faccia qualcosa di pratico e si decida a creare questa benedetta community ufficiale e salvare questa distro?
Tanta gente, come me, non aspetta altro per tornare.