Introduzione

Questa è l'ultima puntata della nostra serie di sviluppo C e probabilmente la più non tecnica. Se ci hai seguito dall'inizio e ti sei esercitato il più possibile, ora hai alcune conoscenze di base sullo sviluppo in C e su come impacchettare la tua applicazione (preferita) per due delle famiglie di distribuzione Linux più utilizzate, Debian e Redhat. Questo articolo riguarda la comunità, come contribuire, come collaborare e, infine, come ottenere il tuo pacchetto negli archivi Debian ufficiali. Se leggi i precedenti articoli della collana non avrai bisogno di altre conoscenze tecniche; tutto ciò di cui hai bisogno è la volontà di mettere le tue conoscenze al servizio del beneficio della comunità.

Per iniziare

Hai un'applicazione, l'hai impacchettata e ora sei ansioso di caricarla negli archivi Debian (a proposito, molte delle idee presentate qui si applicano a molti progetti Open Source:ciò che differisce di solito è il modo di fare le cose). Diciamo non così in fretta. Prenditi un minuto per respirare e trova il modo di farti conoscere dalla comunità. Prenditi del tempo per leggere la Debian New Maintainer's Guide, se non l'hai già fatto, e ricorda la parola chiave qui:community. Tutti sono volontari e abbiamo scelto Debian soprattutto per le sue opinioni democratiche e nessuno è pagato o obbligato in alcun modo a eseguire i tuoi ordini. Ad ogni modo, poiché sappiamo quanto ti piace leggere guide e manuali, parte di questo articolo consisterà in alcuni sani consigli sulla collaborazione. Per prima cosa, abituati a cavartela da solo. A nessuno piace una persona che, quando incontra il primo segnale di guai, invece di andare dal miglior amico di Internet, $SEARCH_ENGINE, inizia a inquinare forum, mailing list e canali IRC con domande puerile come "Di quali flag gcc ho bisogno ho bisogno per compilare il mio codice per i686?". L'unica cosa che guadagnerai è un RTFM poco amichevole e molti punti geek mancanti. Sì, sappiamo che il manuale di gcc è grande e un colpo sicuro per il mal di testa, ma leggere il manuale, quindi cercare prima in rete è il modo giusto (TM). Nessuna eccezione. Farai una prima buona impressione quando mostrerai agli altri sviluppatori che hai fatto i compiti. D'altra parte, dare del filo da torcere ai principianti, specialmente quando un tale comportamento non è richiesto, non ti farà guadagnare popolarità. Ricorda che una volta eri come loro, ricorda che tu, come tutti noi, hai ancora molto da imparare e forse indirizza la persona verso una risorsa che ritieni utile. In questo contesto, ricorda ancora quella parola:comunità. Il tuo lavoro non significa molto, nonostante significhi il mondo per te, a meno che la comunità non lo trovi utile. Collabora con loro e sii pronto ad accettare feedback e sii grato per questo, anche se potrebbe non piacerti quello che senti. Lascia il tuo orgoglio alla porta e ricorda che il miglior e forse l'unico modo per migliorare il tuo software è il feedback della community. Ma non cadere negli estremi e cerca di essere imparziale. Forse alcune persone cercheranno di sminuirti solo per il gusto di farlo:ignorale e concentrati su critiche costruttive.

Strumenti del mestiere

Il primo strumento di cui avrai bisogno come sviluppatore Debian, o qualsiasi altra distribuzione/progetto, è la pazienza. Non importa se stai impacchettando il tuo software o quello di qualcun altro, come abbiamo fatto con yest. Non si diventa sviluppatori dall'oggi al domani, specialmente in un progetto orientato alla qualità come Debian. Ora, per entrare nel lato pratico delle cose, il primo e più ovvio strumento di cui hai bisogno è il compilatore per il linguaggio in cui è scritto il tuo programma. Oppure, se il programma è scritto in un linguaggio interpretato, assicurati che l'interprete (Perl, Python, Ruby...) è presente come dipendenza. Tuttavia, ci concentreremo sul lato C, poiché dopotutto si tratta di una serie di articoli di sviluppo C, e ti forniremo un elenco non esaustivo di utilità che è meglio che tu abbia installato sulla tua macchina di sviluppo:

auto* tools (autoconf, automake, ...)
debhelper and dh-make -- Debian-specific
devscripts, fakeroot -- same, see the Guide for details
a VCS of your choice, depending on the situation at hand -- we prefer to take no sides here
gnupg -- for digitally signing your packages, mandatory in Debian
lintian -- the name is a combination of lint and Debian, so it's self-explanatory
patch - you should know by know why you'd need it
pbuilder -- for creating a chroot

Se fossi stato attento, avresti notato che abbiamo omesso un'utilità importante in quell'elenco. Riesci a individuarlo?

Documentazione

Debian consiglia due documenti. Infatti no. Debian consiglia i due documenti, ma diciamo che è essenziale leggerli più di una volta e tenerli sempre a portata di mano. Queste sono la Debian Policy e il Developers Reference, entrambi disponibili via Web e come pacchetti. Anche gli standard di codifica GNU dovrebbero essere a portata di mano quando ne hai bisogno, specialmente quando/se stai scrivendo l'applicazione da solo.

A monte

Dal momento che ci stiamo concentrando su yest come esempio principale per questa serie, è facile capire che siamo solo packager, non sviluppatori primari, quindi dobbiamo mantenere i contatti con l'upstream. Le regole di comunicazione sopra delineate si applicano, ovviamente, e la stretta collaborazione con l'upstream crea un pacchetto salutare che viene aggiornato tempestivamente non appena l'autore carica la nuova versione. Anche se detto autore probabilmente ha testato il software prima di rilasciarlo in natura, se esegui alcuni test di unità prima di caricare il pacchetto, è ancora meglio. Dai un'occhiata a strumenti come DejaGNU per questo e segnala eventuali problemi rilevati a monte. A proposito di reportistica, devi capire la responsabilità che ti stai assumendo quando diventi responsabile. TUTTE le segnalazioni di bug degli utenti Debian arriveranno a te, ed è tuo dovere agire da catalizzatore tra gli utenti e l'upstream per risolvere tutti i problemi.

Il mentore

Molti di voi, specialmente i più grandicelli come me, hanno visto la serie Karate Kid. Semmai, quel film mostra una relazione tra un maestro e un apprendista (OK, puoi usare anche Star Wars come esempio...). Se pensi di chiedere di diventare uno sviluppatore e il tuo desiderio viene esaudito in pochi minuti, hai dimenticato la pazienza. No, devi prima chiedere un tutoraggio, mostrando i tuoi risultati, le tue motivazioni e così via. Dopo un po', dopo che ti sarai dimostrato degno, presenterai una domanda per diventare un manutentore, con il mentore che garantisce per te.

Caricamento in corso

Ci sei quasi, tutto ciò che devi fare è eseguire il caricamento correttamente. Se sei arrivato così lontano, puoi già darti una pacca sulla spalla. Ora, l'applicazione di cui hai bisogno si chiama dupload(1) e dovresti creare un file chiamato dupload.conf(5) nella tua home directory e inizia a modificare le impostazioni. Puoi, se la pagina di manuale del file sembra spaventosa, prendere /etc/dupload.conf come esempio. Dopo aver salvato ~/dupload.conf , puoi fare qualcosa del genere:

 $ dupload yest-2.7.0.5_i386.changes

Ora, al lettore viene lasciato come esercizio scoprire cos'altro deve essere fatto quando si carica un pacchetto per la prima volta. Inoltre, il capitolo 9 della Debian New Maintainer's Guide dovrebbe essere letto e riletto e poi ancora un po'. Questo è tutto!

Tutti gli articoli di questa serie:

• Io. Sviluppo C su Linux – Introduzione
• II. Confronto tra C e altri linguaggi di programmazione
• III. Tipi, operatori, variabili
• IV. Controllo del flusso
• V. Funzioni
• VI. Puntatori e array
• VII. Strutture
• VIII. I/O di base
• IX. Stile di codifica e consigli
• X. Costruire un programma
• XI. Packaging per Debian e Fedora
• XII. Ottenere un pacchetto nei repository Debian ufficiali