repository per slackware current con vecchi pacchetti

[shark1500]

Ciao a tutti, ho provato a cercare tra i vecchi post di slacky ma non sono riuscito a trovare niente .

Ero sicuro che qualcuno (conraid?) ha scritto sul forum un repository dove c'era la -current e non cancellava i pacchetti precedenti, cosi` se uno dava dei problemi potevi fare il downgrade.

Qualcuno ne conosce qualcuno?

[conraid]

ftp.riken.jp ma non funziona più nel senso che adesso hanno solamente i file aggiornati

[shark1500]

Non ne esistono altri?

[shark1500]

Ho cercato anche io un po` in giro ieri sera e non ho trovato niente, quindi ora provo ad esporre la mia idea (non so se cambiare titolo).

L'idea (che non ho visto in giro) e` di creare un repository slackware sotto git che faccia un commit ogni volta che si aggiorna la current. In questo modo si puo` tornare indietro a piacimento e si possono tenere traccia anche i cambiamenti che ha fatto pat negli SlackBuilds. Potremmo pubblicare il repo sul github di slacky e dopo se uno vuole aggiornare alla current invece dell'rsync fa un 'git pull' (non penso sia un problema la banda per github).

L'unico dubbio e` quanto occupera` in piu` o in meno, ma avevo in mente di ignorare tutti i sorgenti in source, cosi` diventa sicuramente piu` leggero (oppure farne due: uno "pensate" ed uno "leggero" e dare la scelta).

Volevo rintracciare i vecchi pacchetti in modo da iniziare con gia` una history dalla 13.37 ad adesso, pero` sembrano introvabili, quindi si inizierebbe da adesso.

[conraid]

iniziativa interessante

a proposito dei sorgenti, ho visto che alcuni mirror hanno una directory specifica, e dei link da source di slackware64 e slackware, ed in effetti gli slackbuild e tutto il resto sono uguali, è solo un doppione. Quindi potremmo anche noi fare due mirror per i binari, ed un unico mirror per i sorgenti, così chi vuole scarica anche quello.
Per lo spazio chiedo quanto abbiamo

[targzeta]

@shark, in pratica vorresti poter seguire tutti i passaggi fatti da Pat, in modo da avere anche i pacchetti intermedi? Se è così, penso che il consumo del disco sia notevole, anche ammettendo di tenere solo i pacchetti senza nient'altro, c'è da considerare che tutti i t.z sono binari e quindi git deve per forza di cose mantenere tutto su disco.

Emanuele

[shark1500]

@conraid basterebbe mettere un gitignore sotto sources/ cosi` ignora tutti i file .tar.* o una cosa del genere.
@spina se non vado errato git non e` male anche con i file binari, tiene solo i delta ed e` molto veloce, per questo viene usato anche come strumento di backup da altri software.

[edit]@conraid non capisco cosa intendi con "Per lo spazio chiedo quanto abbiamo", io pensavo di metterlo su github cosi` non consumiamo spazio e banda[/edit]

[conraid]

avevo capito qui... ops...

su github se ce lo fanno mettere come progetto opensource sarebbe l'ideale? creiamo un account slacky? o uno apposito per questo?

[targzeta]

Sentiamo Loris che dice, comunque se non abbiamo già un account su github non sarebbe male crearne proprio uno per slacky.

Emanuele

[shark1500]

Esiste gia` un account per slacky, dove c'e` (per ora) solo slackyd (mea culpa che non ho davvero tempo per starci dietro ora).
Secondo me e` un'ottima opportunita` per avere piu` visibilita` e magari ci si puo` pensare se inserire altri progetti su quell'account.

[miklos]

ragazzi.. ma perchè sta cosa di mettere i binari sotto git?!??!!?
pensate davvero che sia una cosa conveniente!??!?!?! piu' conveniente di tenere una directory ftp dove semplicemente non si cancella mai nulla?!?!? tanto non è che si risparmia poi cosi' tanto spazio considerando che i binari possono differire di poco.. ma essere totalmente stravolti (penso alle glib o ai pacchetti ricompilati con una versione nuova di gcc).

inoltre chi per sbaglio cancella il repo che ha in locale.. si deve scaricare, per esempio, l'equivalente di 5 mesi di sviluppi solo per avere l'ultimo pacchetto disponibile.

EDIT: il repo github targato slacky è un'ottima idea.. io proporrei di usarlo per versionare gli slackbuilds (un po' come il repo di ponce)

[shark1500]

ragazzi.. ma perchè sta cosa di mettere i binari sotto git?!??!!?
pensate davvero che sia una cosa conveniente!??!?!?! piu' conveniente di tenere una directory ftp dove semplicemente non si cancella mai nulla?!?!? tanto non è che si risparmia poi cosi' tanto spazio considerando che i binari possono differire di poco.. ma essere totalmente stravolti (penso alle glib o ai pacchetti ricompilati con una versione nuova di gcc).

Invece si risparmia non poco. L'alternativa e` o avere tutti i file doppi oppure solo il delta, inoltre in un attimo se c'e` qualcosa che non funziona si puo` tornare indietro nella history semplicemente creando un nuovo branch.

inoltre chi per sbaglio cancella il repo che ha in locale.. si deve scaricare, per esempio, l'equivalente di 5 mesi di sviluppi solo per avere l'ultimo pacchetto disponibile.

No.
git clone --depth 1 <URL>

Cosi` e` come se facessi un rsync senza nessuna history.

EDIT: il repo github targato slacky è un'ottima idea.. io proporrei di usarlo per versionare gli slackbuilds (un po' come il repo di ponce)

Forse per questo si potrebbe fare un thread a parte, comunque l'account esiste.

[miklos]

ok... quindi se io aggiorno col tuo metodo.. eppoi mi accorgo che il pacchetto ipsilon nn mi funziona e devo tornare indietro che faccio?!?!?!
comunque boh.. io penso ad un file musicale e posso pure capire che il delta sia abbastanza ridotto.. ma sugli eseguibili sta cosa non mi torna tanto.. ma vabbe.. ammetto di non averlo mai provato

ad ogni modo ho trovato questoche forse rende git un po' piu' decente in questo senso.

[shark1500]

ok... quindi se io aggiorno col tuo metodo.. eppoi mi accorgo che il pacchetto ipsilon nn mi funziona e devo tornare indietro che faccio?!?!?!

Codice: Seleziona tutto

git branch before HEAD~1
git checkout before


e magicamente troverai il pacchetto alla versione precedente, e ovviamente questo funziona anche offline (a differenza di tutti gli altri metodi)

comunque boh.. io penso ad un file musicale e posso pure capire che il delta sia abbastanza ridotto.. ma sugli eseguibili sta cosa non mi torna tanto.. ma vabbe.. ammetto di non averlo mai provato

Ci si puo` provare, se poi non va bene si cerca una via alternativa. Il bello e` che una volta che si inizia con il git dopo si puo` tornare indietro quanto si vuole per "creare" l'alternativa (es: rsync senza cancellare).

[miklos]

guarda git un po' lo conosco.. non mi definisco un genio.. pero' ho piu' delle basi(fra l'altro quando ti ho detto come si faceva a tornare indietro, mi riferivo al tuo comando che ignorava la history)
il discorso mi suona un po' strano per principio.. ma non l'ho mai fatto quindi ho sollevato la mia perplessità.. ma sono sempre pronto a scoprire cose nuove:)