Re: Proporre un .deb?
On Sun, Feb 22, 2004 at 05:05:04PM +0100, Domenico Andreoli wrote: Ciao, nome pacchetto: foo versione attuale: 1.0 versione pre-release: 1.1rc3 in questa situazione pubblico il pacchetto foo con versione 1.0+1.1rc3-1. in questo modo chi installa il pacchetto capisce chiaramente che in realta' si tratta di una prerelease. la versione e' sicuramente un po' bruttina ma nella maggior parte dei casi dovrebbe essere solo temporanea e quindi me ne frego. quando uscira' foo 1.1 allora lo pubblichero' con version 1.1-1 e l'upgrade avverra' senza problemi. Altra tecnica funzionale e` quella di allungare la versione upstream in modo fittizio... Utile soprattutto se si e` gia` fatto l'upload... Eg: 1.0beta1 1.0.0 1.1rc2 1.1.0 direi che alcune soluzioni da studiare per risolvere questo genere di problemi di versioning sono quelle adottate dai seguenti pacchetti: glibc, gcc, xfig. cosi' su due piedi non me ne vengono in mente altri. Beh, dopo l'uscita di sarge si potra` semplicemente usare la ~ come operatore di abbassamento di versione, con una semantica di x~y x bastera` quindi chiamare l'eventuale beta o rc 1.0~beta1 1.1~rc2 ecc... :) Ciao, Guido
Re: Proporre un .deb?
On Sat, Feb 21, 2004 at 08:40:07PM +0100, GHERdO wrote: Mi domandavo se questo fosse il posto giusto per proporre un pacchetto per il momento inedito in debian. Cosa intendi per proporre? 1) chiedere la pacchettizzazione di un software attualmente non pacchettizzato 2) chiedere review/sponsorizzazione per l'upload di un pacchetto che hai realizzato tu (Da quello che scrivi sotto immagino sia (2), comunque ...) Per (1) la procedura giusta e' di inviare un bugreport di tipo RFP, se installi reportbug basta che lo invochi e ti lasci guidare da lui per bug sul metapacchetto wnpp. Per (2) la mailing list giusta su cui fare la richiesta e' [EMAIL PROTECTED] Ciao -- Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy [EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/ If there's any real truth it's that the entire multidimensional infinity of the Universe is almost certainly being run by a bunch of maniacs. -!- signature.asc Description: Digital signature
Re: Proporre un .deb?
Stefano Zacchiroli [EMAIL PROTECTED] scriveva: SZ Cosa intendi per proporre? [...] SZ 2) chiedere review/sponsorizzazione per l'upload di un pacchetto SZ che hai realizzato tu SZ (Da quello che scrivi sotto immagino sia (2), comunque ...) Esatto: la parte che mi interessava era quella di review e correzione selvaggia e violenta al fine di miglioramento :) -- GHERdO, happy GNU/linux user. ... Boys don't Cry!
Re: Proporre un .deb?
On Sun, Feb 22, 2004 at 03:48:17PM +0100, Stefano Zacchiroli wrote: On Sun, Feb 22, 2004 at 03:45:47PM +0100, GHERdO wrote: Esatto: la parte che mi interessava era quella di review e correzione selvaggia e violenta al fine di miglioramento :) Invia quindi una mail su debian-mentors chiedendo che qualcuno sia tuo sponsor. L'ideale e' che tu indichi nella mail di che pacchetto si tratta, quale licenza ha ecc. e dove si puo' scaricare cio' che hai fatto (comprensivo di tarball, diff.gz, i .deb sono secondari). cio' non toglie che se posti queste informazioni anche su questa mailing list qualcuno possa essere interessato e ti risponda. ciao domenico -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: Proporre un .deb?
On Sun, Feb 22, 2004 at 04:07:10PM +0100, GHERdO wrote: Domenico Andreoli [EMAIL PROTECTED] scriveva: DA cio' non toglie che se posti queste informazioni anche su questa DA mailing list qualcuno possa essere interessato e ti risponda. Arrivo: bastonate pure, che imparo pi? in fretta :) ok :) bastonata livello_di_utilita=lo ammetto, non troppo alto il pacchetto e' abbastanza semplice, non potevi sbagliare in troppi punti e non l'hai fatto :))) /bastonata pam_usb is a PAM module that enables authentication using an USB-Storage device (such as an USB Pen) through DSA private/public keys. It can also work with other devices, such as floppy disks or cdroms. It can be setup to work with any application using PAM such as your system login (login), your X login (XDM/KDM/GDM/...), your screensaver (xscreensaver/...), and many others. It supports multiple users for the same device, multiple hostnames for the same user, serial numbers access list and private key encryption. uh.. ma che bellino, avevo gia' adocchiato l'ITP.. l'unica osservazione che credo valga la pena di farti e' di diffidare dalle versioni upstream tipo 0.2rc2. sono molto comode e leggibili ma non appena l'upstream decide di rilasciare la 0.2 tu sei nei pasticci perche' 0.2rc2 e' considerata da dpkg maggiore di 0.2 (usa dpkg --compare-versions quando hai dei dubbi) e il pacchetto non ti si aggiorna. a questo punto l'unica via di uscita e' di usare le epochs e pubblicare il pacchetto con versione 1:0.2. l'epochs pero' sporcano un po' la versione e non ho mai visto nessuno che le usasse con troppo piacere. io personalmente cerco sempre di evitarle, anche perche' una volta che inizi con le epochs o cambi il nome al pacchetto o non te le levi piu' di dosso. rant introdurre le epoch perche' non si e' stati capaci de gestire le pre-release e cose del genere e' da babbione. o almeno io mi considererei tale se ci cascassi. tu non vuoi diventare babbione nel giro di tre uploads, vero? : /rant per prevenire simili problemi non credo ci sia una strategia standard, ti posso fare solo un esemprio di come faccio io: nome pacchetto: foo versione attuale: 1.0 versione pre-release: 1.1rc3 in questa situazione pubblico il pacchetto foo con versione 1.0+1.1rc3-1. in questo modo chi installa il pacchetto capisce chiaramente che in realta' si tratta di una prerelease. la versione e' sicuramente un po' bruttina ma nella maggior parte dei casi dovrebbe essere solo temporanea e quindi me ne frego. quando uscira' foo 1.1 allora lo pubblichero' con version 1.1-1 e l'upgrade avverra' senza problemi. direi che alcune soluzioni da studiare per risolvere questo genere di problemi di versioning sono quelle adottate dai seguenti pacchetti: glibc, gcc, xfig. cosi' su due piedi non me ne vengono in mente altri. quindi, come vedi, il discorso puo' complicarsi a piacere. di coseguenza finche' puoi, evita di fare casini con le versioni. fortunatamente sei ancora in tempo per non usare le epoch visto che il tuo pacchetto non e' ancora in main (vero?). ciao domenico -[ Domenico Andreoli, aka cavok --[ http://filibusta.crema.unimi.it/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
