Difference between revisions of "VCS package guidelines (Italiano)"

From ArchWiki
Jump to: navigation, search
(creata pagina)
 
(use https for links to archlinux.org)
(18 intermediate revisions by 5 users not shown)
Line 1: Line 1:
[[Category:Package development (English)]]
+
[[Category:Package development (Italiano)]]
[[Category:Guidelines (English)]]
+
[[en:VCS PKGBUILD Guidelines]]
{{i18n|VCS PKGBUILD Guidelines}}
+
[[zh-CN:VCS PKGBUILD Guidelines]]
{{Article summary start}}
+
[[zh-TW:VCS PKGBUILD Guidelines]]
{{Article summary text|Creating PKGBUILDs for software managed with version control systems.}}
+
{{Package Guidelines (Italiano)}}
{{Article summary heading|Related}}
+
{{Article summary wiki|Arch Build System}}
+
{{Article summary wiki|Arch User Repository}}
+
{{Article summary wiki|Creating Packages}}
+
{{Article summary wiki|makepkg}}
+
{{Article summary wiki|pacman}}
+
{{Article summary wiki|PKGBUILD}}
+
{{Article summary end}}
+
  
Guidelines for creating PKGBUILDs for software managed with version control systems.
+
I sistemi di controllo di versioni possono essere usati per il recupero sia delle versioni dei pacchetti ufficialmente rilasciati, sia per quelle in sviluppo (trunk). Quest'articolo copre entrambi i casi.
  
== Prototypes ==
+
== Prototipi ==
  
The {{Package Official|abs}} package provides prototypes for cvs, svn, git, mercurial, and darcs PKGBUILDs. When abs is installed, you can find them in {{Filename|/usr/share/pacman}}.
+
Il pacchetto {{Pkg|abs}} fornisce prototipi per PKGBUILDs relativi a software prelevabile da repository svn, git, mercurial, e darcs. Una volta installato il pacchetto abs, è possibile reperirli all'interno della directory {{ic|/usr/share/pacman}}. Oppure navigare la directory [https://projects.archlinux.org/abs.git/tree/prototypes prototypes] nel repository Git di [[ABS]]
  
== Guidelines ==
+
== Linee guida ==
  
* Properly suffix {{Codeline|pkgname}} with {{Codeline|-cvs}}, {{Codeline|-svn}}, {{Codeline|-hg}}, {{Codeline|-darcs}}, {{Codeline|-bzr}} or {{Codeline|-git}}. If the package tracks a moving development trunk it should be given a suffix. If the package fetches a release from a VCS tag then it should not be given a suffix. Use this rule of thumb: if the output of the package depends on the time at which it was compiled, append a suffix; otherwise do not.
+
* Apporre il suffisso appropriato al {{ic|pkgname}} scegliendo tra {{ic|-cvs}}, {{ic|-svn}}, {{ic|-hg}}, {{ic|-darcs}}, {{ic|-bzr}} or {{ic|-git}}. Se il pacchetto fa riferimento ad un ramo in sviluppo, dovrebbe essergli aggiunto un suffisso. Se il pacchetto scarica i sorgenti da un tag VCS, non si dovrebbe aggiungere nulla. Utilizzare questa regola comportamentale: se la riuscita del pacchetto dipende dalla data di compilazione, aggiungere un suffisso; altrimenti non farlo.
  
* When [[makepkg]] is run, by default it will check for newer revisions and then update the {{Codeline|pkgver}} in the PKGBUILD. Look at {{Codeline|--holdver}} in [http://www.archlinux.org/pacman/makepkg.8.html man makepkg] if you want otherwise.  {{Codeline|--holdver}} only works for cvs and svn, which allow checkout of older revisions.
+
* Un pacchetto VCS può essere aggiornato nel momento in cui si renda necessaria una modifica al sistema di compilazione, incluse correzioni di dipendenze, URL, indirizzi sorgente, etc. Se il numero di revisione rimane lo stesso dopo un aggiornamento di questo ripo, ma viene generato un binario differente, l'incremento manuale della variabile {{ic|pkgrel}} è obbligatorio. Se sia il numero di revisione che il binario rimangono inalterati, {{ic|pkgrel}} può essere lasciato invariato. Non è necessario aggiornare un pacchetto VCS per ogni commit che raggiunge il repo di revision control, ma si potrebbe anche farlo.
  
* Check for package conflicts.  For example ''fluxbox-svn'' will conflict with ''fluxbox''. In this case, you need to use {{Codeline|1=conflicts=('fluxbox')}}.
+
* Quando [[makepkg]] viene eseguito, di default controllerà la presenza di nuove revisioni ed aggiornerà il valore di {{ic|pkgver}} all'interno del PKGBUILD. Consultare {{ic|--holdver}} in [https://www.archlinux.org/pacman/makepkg.8.html man makepkg] se si vuole imporre un comportamento differente. {{ic|--holdver}} funziona solo per repository CVS ed SVN, che consentono l'utilizzo di sorgenti di revisioni precedenti.
  
* Use the {{Codeline|provides}} field so that packages that require the non-VCS package can be installed ({{Codeline|1=provides=('fluxbox')}}).
+
* Verificare i conflitti del pacchetto. Per esempio ''fluxbox-svn'' andrà in conflitto con ''fluxbox''. In questo caso sarà necessario utilizzare {{ic|1=conflicts=('fluxbox')}}.
  
* You should AVOID using {{Codeline|1=replaces=...}} as it generally causes unnecessary problems.
+
* Utilizzare il campo {{ic|provides}} in modo che le dipendenze dei pacchetti che richiedono la presenza della versione non-CVS del pacchetto da generare risultino soddisfatte ({{ic|1=provides=('fluxbox')}}).
  
* When using/defining the cvsroot, use {{Codeline|anonymous:@}} rather than {{Codeline|anonymous@}} to avoid a password prompt and having to enter a blank password ''OR'' use {{Codeline|anonymous:password@}} if a password is required.
+
* Bisognerebbe cercare di evitare, ove possibile, l'utilizzo di {{ic|1=replaces=...}}, in quanto genera facilmente problemi che sarebbe meglio evitare.
  
* Though it is often unnecessary to use the {{Codeline|pkgrel}} field when building CVS/SVN/GIT packages (changes to the package are usually often and will be reflected in the {{Codeline|pkgver}}), makepkg will require it.
+
* Quando si definisce la root CVS, utilizzare  {{ic|anonymous:@}} piuttosto che {{ic|anonymous@}} per evitare la richiesta di password e l'obbligo di inserire una password vuota, ''O'' utilizzare {{ic|anonymous:password@}} nel caso una password sia necessaria.
  
* Don't forget to include the appropriate VCS tool (cvs, subversion, git, ...) in {{Codeline|1=makedepends=...}}.
+
* Nonostante non sarebbe necessario utilizzare il campo {{ic|pkgrel}} quando si compila da repo CVS/SVN/GIT (in quanto i cambiamenti ai sorgenti sono frequenti, e saranno automaticamente notificati nel campo {{ic|pkgver}}), makepkg lo richiede obbligatoriamente.
  
* To preserve the integrity of the checked-out code consider copying the original build directory if you have to make edits.  For example, having checked out source code to {{Filename|src/$_cvsmod}} from {{Filename|$startdir}} you can use:
+
* Non dimenticare di includere il tool VCS appropriato (cvs, subversion, git, ...) all'interno dell'array {{ic|1=makedepends=...}}.
  
 +
* Per preservare l'integrità del codice originale scaricato, prendere in considerazione di copiare la directory di compilazione, se si presenta la necessità di effettuare modifiche al sorgente. Ad esempio, considerando di aver effettuato il check out dal repo in {{ic|src/$_cvsmod}} da {{ic|$startdir}}, ci si può comportare in questo modo
 
  mkdir src/$_cvsmod-build
 
  mkdir src/$_cvsmod-build
 
   
 
   
Line 44: Line 37:
 
  ../$_cvsmod/configure
 
  ../$_cvsmod/configure
  
or:
+
o:
  
 
  cp -r src/$_cvsmod src/$_cvsmod-build
 
  cp -r src/$_cvsmod src/$_cvsmod-build
 
  cd src/$_cvsmod-build
 
  cd src/$_cvsmod-build
  
* With the introduction of the [[AUR]], it is most important to avoid using backtick execution to create package variables. makepkg will automatically bump the {{Codeline|pkgver}} anyway when building the package (unless {{Codeline|--holdver}} is used).
+
* Con l'introduzione di [[AUR]], è importante evitare l'esecuzione degli apici inversi per la creazione di variabili del pacchetto. Makepkg aggiornerà automaticamente il campo {{ic|pkgver}} in ogni caso durante la compilazione del pacchetto ( a meno che non venga utilizzato {{ic|--holdver}})
 +
 
 +
== Suggerimenti ==
 +
 
 +
* Bisognerebbe accertarsi che non vengano lasciate directory proprie del VCS all'interno del pacchetto. Nel caso risultassero presenti, si potrebbe modificare la sezione package() del PKGBUILD aggiungendole in fondo una riga simile a questa per rimuoverle.
 +
 
 +
{{bc|rm -rf `find "$pkgdir" -type d -name ".svn"`}}
 +
 
 +
* Utilizzando GIT, è possibile velocizzare le operazioni di clonazione tramite il parametro {{ic|1=--depth=1}}. In questo modo viene effettuata una copia superficiale, che contiene solo l'ultima parte della cronologia dei cambiamenti - dato che la precedente è solitamente inutili ai fini della compilazione.
 +
 
 +
{{bc| git clone git://hostname.dom/project.git --depth<nowiki>=</nowiki>1}}
 +
 
 +
* È possibile creare il pacchetto anche da un branch diverso dal master. Per farlo basta aggiungere un {{ic|1=--branch nome_branch}} dopo il primo {{ic|1=git clone}}, in questo modo:
 +
 
 +
{{bc| git clone "$_gitroot" "$_gitname" --branch nome_branch}}
 +
Ricordarsi di rinominare il pacchetto in {{ic|1= pacchetto-branch-git}} per evitare confusione con l'eventuale pacchetto dal branch master.
 +
 
 +
* Porzione di codice da copia/incollare per la compilazione da repo VCS:
 +
Per i pigri, è mostrato un semplice script di compilazione da repo GIT
 +
 
 +
{{bc|<nowiki>cd "$srcdir"
 +
msg "Connecting to GIT server...."
 +
if [ -d $_gitname ] ; then
 +
  cd $_gitname && git pull origin
 +
  msg "The local files are updated."
 +
else
 +
  git clone --depth=1 $_gitroot $_gitname
 +
fi
 +
msg "GIT checkout done or server timeout"
 +
</nowiki>
 +
}}
 +
 
 +
* Directory temporanee di compilazione: Utilizzando GIT, ed avendo la necessità di creare una directory di compilazione separata, bisognerebbe evitare di copiare la directory {{Ic|1=.git}} all'interno della directory principale, visto che questa contiene informazioni sullo storico che GIT utilizza internamente. Nei repo con migliaia di commit, questa directory {{Ic|1=.git}} può contenere anche centinaia di MiB di unitile storico dei commit che non hanno nulla a che vedere con l'attuale albero di lavoro. L'unico caso in cui si potrebbe aver bisogno di copiare anche la directory {{Ic|1=.git}}, è quando si dovesse compilare uno specifico vecchio commit (eventualità molto remota, visto che lo scopo di un pacchetto VCS è proprio quello di fornire l'ultimo codice disponibile). Quindi, invece di
 +
 
 +
{{bc| rm -rf "$srcdir/$_gitname-build"
 +
cp -R "$srcdir/$_gitname" "$srcdir/$_gitname-build" # copia tutto, inclusa l'inutile directory .git
 +
cd "$srcdir/$_gitname-build"
 +
make # build/compile from source
 +
}}
 +
 
 +
si dovrebbe utilizzare
 +
 
 +
{{bc| rm -rf "$srcdir/$_gitname-build"
 +
cd "$srcdir/$_gitname" && ls -A | grep -v .git | xargs -d '\n' cp -r -t ../$_gitname-build # non copia la directory .git
 +
cd "$srcdir/$_gitname-build"
 +
make # build/compile from source
 +
}}
 +
 
 +
per abbattere il tempo di compilazione e lo spazio utilizzato.

Revision as of 01:59, 6 December 2012

I sistemi di controllo di versioni possono essere usati per il recupero sia delle versioni dei pacchetti ufficialmente rilasciati, sia per quelle in sviluppo (trunk). Quest'articolo copre entrambi i casi.

Prototipi

Il pacchetto abs fornisce prototipi per PKGBUILDs relativi a software prelevabile da repository svn, git, mercurial, e darcs. Una volta installato il pacchetto abs, è possibile reperirli all'interno della directory /usr/share/pacman. Oppure navigare la directory prototypes nel repository Git di ABS

Linee guida

  • Apporre il suffisso appropriato al pkgname scegliendo tra -cvs, -svn, -hg, -darcs, -bzr or -git. Se il pacchetto fa riferimento ad un ramo in sviluppo, dovrebbe essergli aggiunto un suffisso. Se il pacchetto scarica i sorgenti da un tag VCS, non si dovrebbe aggiungere nulla. Utilizzare questa regola comportamentale: se la riuscita del pacchetto dipende dalla data di compilazione, aggiungere un suffisso; altrimenti non farlo.
  • Un pacchetto VCS può essere aggiornato nel momento in cui si renda necessaria una modifica al sistema di compilazione, incluse correzioni di dipendenze, URL, indirizzi sorgente, etc. Se il numero di revisione rimane lo stesso dopo un aggiornamento di questo ripo, ma viene generato un binario differente, l'incremento manuale della variabile pkgrel è obbligatorio. Se sia il numero di revisione che il binario rimangono inalterati, pkgrel può essere lasciato invariato. Non è necessario aggiornare un pacchetto VCS per ogni commit che raggiunge il repo di revision control, ma si potrebbe anche farlo.
  • Quando makepkg viene eseguito, di default controllerà la presenza di nuove revisioni ed aggiornerà il valore di pkgver all'interno del PKGBUILD. Consultare --holdver in man makepkg se si vuole imporre un comportamento differente. --holdver funziona solo per repository CVS ed SVN, che consentono l'utilizzo di sorgenti di revisioni precedenti.
  • Verificare i conflitti del pacchetto. Per esempio fluxbox-svn andrà in conflitto con fluxbox. In questo caso sarà necessario utilizzare conflicts=('fluxbox').
  • Utilizzare il campo provides in modo che le dipendenze dei pacchetti che richiedono la presenza della versione non-CVS del pacchetto da generare risultino soddisfatte (provides=('fluxbox')).
  • Bisognerebbe cercare di evitare, ove possibile, l'utilizzo di replaces=..., in quanto genera facilmente problemi che sarebbe meglio evitare.
  • Quando si definisce la root CVS, utilizzare anonymous:@ piuttosto che anonymous@ per evitare la richiesta di password e l'obbligo di inserire una password vuota, O utilizzare anonymous:password@ nel caso una password sia necessaria.
  • Nonostante non sarebbe necessario utilizzare il campo pkgrel quando si compila da repo CVS/SVN/GIT (in quanto i cambiamenti ai sorgenti sono frequenti, e saranno automaticamente notificati nel campo pkgver), makepkg lo richiede obbligatoriamente.
  • Non dimenticare di includere il tool VCS appropriato (cvs, subversion, git, ...) all'interno dell'array makedepends=....
  • Per preservare l'integrità del codice originale scaricato, prendere in considerazione di copiare la directory di compilazione, se si presenta la necessità di effettuare modifiche al sorgente. Ad esempio, considerando di aver effettuato il check out dal repo in src/$_cvsmod da $startdir, ci si può comportare in questo modo
mkdir src/$_cvsmod-build

cd src/$_cvsmod-build
../$_cvsmod/configure

o:

cp -r src/$_cvsmod src/$_cvsmod-build
cd src/$_cvsmod-build
  • Con l'introduzione di AUR, è importante evitare l'esecuzione degli apici inversi per la creazione di variabili del pacchetto. Makepkg aggiornerà automaticamente il campo pkgver in ogni caso durante la compilazione del pacchetto ( a meno che non venga utilizzato --holdver)

Suggerimenti

  • Bisognerebbe accertarsi che non vengano lasciate directory proprie del VCS all'interno del pacchetto. Nel caso risultassero presenti, si potrebbe modificare la sezione package() del PKGBUILD aggiungendole in fondo una riga simile a questa per rimuoverle.
rm -rf `find "$pkgdir" -type d -name ".svn"`
  • Utilizzando GIT, è possibile velocizzare le operazioni di clonazione tramite il parametro --depth=1. In questo modo viene effettuata una copia superficiale, che contiene solo l'ultima parte della cronologia dei cambiamenti - dato che la precedente è solitamente inutili ai fini della compilazione.
 git clone git://hostname.dom/project.git --depth=1
  • È possibile creare il pacchetto anche da un branch diverso dal master. Per farlo basta aggiungere un --branch nome_branch dopo il primo git clone, in questo modo:
 git clone "$_gitroot" "$_gitname" --branch nome_branch

Ricordarsi di rinominare il pacchetto in pacchetto-branch-git per evitare confusione con l'eventuale pacchetto dal branch master.

  • Porzione di codice da copia/incollare per la compilazione da repo VCS:

Per i pigri, è mostrato un semplice script di compilazione da repo GIT

cd "$srcdir"
 msg "Connecting to GIT server...."
 if [ -d $_gitname ] ; then
   cd $_gitname && git pull origin
   msg "The local files are updated."
 else
   git clone --depth=1 $_gitroot $_gitname
 fi
 msg "GIT checkout done or server timeout"

  • Directory temporanee di compilazione: Utilizzando GIT, ed avendo la necessità di creare una directory di compilazione separata, bisognerebbe evitare di copiare la directory .git all'interno della directory principale, visto che questa contiene informazioni sullo storico che GIT utilizza internamente. Nei repo con migliaia di commit, questa directory .git può contenere anche centinaia di MiB di unitile storico dei commit che non hanno nulla a che vedere con l'attuale albero di lavoro. L'unico caso in cui si potrebbe aver bisogno di copiare anche la directory .git, è quando si dovesse compilare uno specifico vecchio commit (eventualità molto remota, visto che lo scopo di un pacchetto VCS è proprio quello di fornire l'ultimo codice disponibile). Quindi, invece di
 rm -rf "$srcdir/$_gitname-build"
cp -R "$srcdir/$_gitname" "$srcdir/$_gitname-build" # copia tutto, inclusa l'inutile directory .git
cd "$srcdir/$_gitname-build"
make # build/compile from source

si dovrebbe utilizzare

 rm -rf "$srcdir/$_gitname-build"
cd "$srcdir/$_gitname" && ls -A 

per abbattere il tempo di compilazione e lo spazio utilizzato.