slacky.eu

So bene che la mia proposta è di ben difficile attuazione ma penso di venire incontro a quei tanti che, come me, non hanno affatto gradito l'arrivo di Slack 13.0, in particolar modo riguardo alla scelta (IMVHO opinabile) di adottare KDE4 come ambiente desktop predefinito.
Non entro nei dettagli (la 13.0 mi piace, le mie perplessità sono soltanto di carattere estetico e non riguardano la distro in sé), ma butto giù una proposta operativa: con l'arrivo della 13.0 di sicuro il repository della 12.2 è stato congelato.
C'è la possibilità di mantenerlo in vita, compatibilmente con le impostazioni del database asche e ricompilare in questo modo almeno i pacchetti fondamentali?
C'è qualcuno disposto ad avviare questa ricompilazione in parallelo (12.2 e 13.0) o in alternativa soltanto sulla 12.2?

Burroughs.

Qualcuno lo aveva chiesto nel forum dei pacchettizzatori poco fa. Il repo della 12.2 e` freezato.
Se vuoi aggiornare dei pacchetti mi sa che dovrai farlo "a mano" con gli slackbuild gia` pronti (come fanno quelli con la slackware64), oppure provi il pacchetto della 13.0 (sconsigliabile).

Magari quando si e` finito di ricompilare tutto per la 13.0 (ci vorra` un po`) si puo` pensare se fare qualcosa sul 12.2, ma questa e` solo la mia idea.

Io pensavo di creare almeno un archivio con solo e tutto gli SB (quelli di eventuali nuovi pacchetti), magari rendendo standard l'inserimento del download automatico all'interno dell script stesso. Poco spazio e funziona comunque...
Al massimo uno slackyd che funziona solo a SlackBuild (praticamente portage per Slackware ihih)

jimmy_page_89 ha scritto: Al massimo uno slackyd che funziona solo a SlackBuild (praticamente portage per Slackware ihih)

sbopkg

conraid ha scritto:

jimmy_page_89 ha scritto: Al massimo uno slackyd che funziona solo a SlackBuild (praticamente portage per Slackware ihih)

sbopkg

bel nome

shark1500 ha scritto:Qualcuno lo aveva chiesto nel forum dei pacchettizzatori poco fa. Il repo della 12.2 e` freezato.
Se vuoi aggiornare dei pacchetti mi sa che dovrai farlo "a mano" con gli slackbuild gia` pronti (come fanno quelli con la slackware64), oppure provi il pacchetto della 13.0 (sconsigliabile).

Magari quando si e` finito di ricompilare tutto per la 13.0 (ci vorra` un po`) si puo` pensare se fare qualcosa sul 12.2, ma questa e` solo la mia idea.

Sì, ho appena letto il messaggio di cui parli.
Beh, per esperienza ti posso dire (e tu mi puoi confermare) che ci vogliono almeno 4-5 mesi per ultimare la ricompilazione di un repository aggiornato.

jimmy_page_89 ha scritto:Io pensavo di creare almeno un archivio con solo e tutto gli SB (quelli di eventuali nuovi pacchetti), magari rendendo standard l'inserimento del download automatico all'interno dell script stesso. Poco spazio e funziona comunque...
Al massimo uno slackyd che funziona solo a SlackBuild (praticamente portage per Slackware ihih)

Questa mi sembra una gran bella idea!
In pratica si tratterebbe di varare un progetto simile a quello di slackbuilds.org...
Fra l'altro non porterebbe nemmeno via tanto tempo; chi vuole può scegliere se aggiornarsi da sé il pacchetto o sfruttare i nostri SB.

Burroughs.

Esattamente..tanto ogni programma richiede solo 3 file di testo: SlackBuild, slack.desc e slack.required
Immaginali compressi con tar.bz2..anche solo in 100MB vedi quanti pacchetti ci fai stare

jimmy_page_89 ha scritto:

conraid ha scritto:

jimmy_page_89 ha scritto: Al massimo uno slackyd che funziona solo a SlackBuild (praticamente portage per Slackware ihih)

sbopkg

bel nome

oh my god [-o<

http://www.sbopkg.org/

ops..
come non detto...idea già esistente

Inoltre i pacchetti più gettonati sono sempre quelli ... ovvero Firefox, Thunderbird, Flash, Skype etc.
Avere una lista dei pacchetti più scaricati non sarebbe male ...

Anche io sono tornato alla 12.2 perché ho trovato KDE 4 ancora incompleto e incoerente.
Poi ci sono anche dei bug (Konsole non mi memorizza le scorciatoie), secondo me non è adatto a una stabile.
Perciò io sarei anche disponibile a mantenere il repository per la 12.2.

jimmy_page_89 ha scritto:Io pensavo di creare almeno un archivio con solo e tutto gli SB (quelli di eventuali nuovi pacchetti), magari rendendo standard l'inserimento del download automatico all'interno dell script stesso. Poco spazio e funziona comunque...
Al massimo uno slackyd che funziona solo a SlackBuild (praticamente portage per Slackware ihih)

Io credo che il problema non sia lo spazio: quando si aggiorna un pacchetto si elimina quello vecchio, o no?

conraid ha scritto:oh my god [-o<

http://www.sbopkg.org/

Beh? È un bel nome comunque.

anycolouryoulike ha scritto:Io credo che il problema non sia lo spazio: quando si aggiorna un pacchetto si elimina quello vecchio, o no?

be un conto sono una media di 3-5 mega per un tgz/txz, un altro pochi kb per un SB non credi?
lo spazio è risparmiato sul server, e il consumo di banda decisamente minore

gigiobagiano ha scritto:Offtopic: Se posso inserirmi come sfruttatore di pacchetti, sbopkg è un'ottima soluzione e direi anche molto semplice fino a che non entrano in gioco le dipendenze (oltre a quelle strettamente necessarie al funzionamento servono anche quelle per la compilazione), compilazione, installazione. Se si volesse fare un programma di questo genere, secondo me, si finirebbe per soppiantare completamente pkgtool&co...

Offtopic: ben basterebbe impostare il programma in modo che legga dall slack-required di ogni SB e verifichi se ci sono....se non ci sono scarica l'SB della dipendenza e compila, installa e poi fa il primo.
E' roba molto semplice, con un minimo di conoscenze adeguate di scripting si potrebbe fare senza problemi

Non ci sono praticamente differenze tra gli slackbuild delle varie versioni di slackware, se non per quanto riguarda le versioni dei pacchetti. Mantenere tutto un repository penso sia difficile (su questo può pronunciarsi Loris), soprattutto in vista di un futuro repository a 64bit (che già di suo rappresenta un doppio lavoro rispetto all'attuale situazione). Storicizzare "solo" gli slackbuild, gli slack-required, gli slack-desc e le eventuali patch è invece un'idea più furba e nemmeno troppo dispendiosa, in effetti. In realtà, può già metterla in pratica chiunque fintanto che il repository è al suo posto.