Difference between revisions of "Arch packaging standards (Italiano)"

From ArchWiki
Jump to: navigation, search
m
m (Portuguese added)
(8 intermediate revisions by 4 users not shown)
Line 1: Line 1:
[[Category:About Arch (Italiano)]]
+
[[Category:About Arch (Italiano)]]
 
[[Category:Package management (Italiano)]]
 
[[Category:Package management (Italiano)]]
 
[[Category:Package development (Italiano)]]
 
[[Category:Package development (Italiano)]]
[[Category:Guidelines (Italiano)]]
+
[[en:Arch Packaging Standards]]
{{i18n|Arch Packaging Standards}}
+
[[es:Arch Packaging Standards]]
{{translateme}}
+
[[fr:Standard paquetage]]
 
+
[[pt:Arch Packaging Standards]]
{{note|Pagina In traduzione - fare riferimento per ora alla corrispettiva pagina inglese}}
+
[[ru:Arch Packaging Standards]]
 +
[[sr:Arch Packaging Standards]]
 +
[[zh-CN:Arch Packaging Standards]]
 +
[[zh-TW:Arch Packaging Standards]]
 
==Standard di Pacchettizzazione==
 
==Standard di Pacchettizzazione==
'''I PKGBUILD messi su AUR dagli utenti NON DEVONO riferirsi ad applicazioni già presenti nei repository ufficiali in nessuna circostanza. Eccezione a questa regola sono quei pacchetti compilati con particolari funzionalità abilitate e\o patch applicate differenti da quelle dei pacchetti ufficiali. In questi casi, la voce pkgname deve essere differente, di modo da comunicare chiaramente le differenze dai pacchetti presenti nei repo.'''
+
'''I PKGBUILD messi su AUR dagli utenti NON DEVONO riferirsi ad applicazioni già presenti nei repository ufficiali in nessuna circostanza. Eccezione a questa regola sono quei pacchetti compilati con particolari funzionalità abilitate e/o patch applicate differenti da quelle dei pacchetti ufficiali. In questi casi, la voce pkgname deve essere differente, in modo da comunicare chiaramente le differenze dai pacchetti presenti nei repo.'''
  
Nella realizzazione di pacchetti per Arch Linux, dovreste '''aderire alle linee guida per la pacchettizzazione''' elencate qui sotto, sopratutto se avete intenzione di caricare il vostro PKGBUILD su {{AUR}}. Fare riferimento inoltre alle pagine manuali di [http://archlinux.org/pacman/PKGBUILD.5.html PKGBUILD] e di
+
Nella realizzazione di pacchetti per Arch Linux, si dovrebbe '''aderire alle linee guida per la pacchettizzazione''' elencate qui sotto, soprattutto se avete intenzione di caricare il vostro PKGBUILD su [[AUR]]. Fare riferimento inoltre alle pagine di manuale di [http://archlinux.org/pacman/PKGBUILD.5.html PKGBUILD] e di
 
[http://archlinux.org/pacman/makepkg.8.html makepkg].
 
[http://archlinux.org/pacman/makepkg.8.html makepkg].
  
 
====Prototipo di PKGBUILD====
 
====Prototipo di PKGBUILD====
 +
<pre>
 +
# Maintainer: Your Name <youremail at domain dot com>
 +
 +
pkgname=NAME
 +
pkgver=VERSION
 +
pkgrel=1
 +
pkgdesc=""
 +
arch=('i686' 'x86_64')
 +
url="http://ADDRESS/"
 +
license=('GPL')
 +
groups=()
 +
depends=()
 +
makedepends=()
 +
optdepends=()
 +
provides=()
 +
conflicts=()
 +
replaces=()
 +
backup=()
 +
options=()
 +
install=
 +
source=($pkgname-$pkgver.tar.gz)
 +
noextract=()
 +
md5sums=() #generate with 'makepkg -g'
  
# Maintainer: Nome <vostraemail at dominio punto com>
+
build() {
pkgname=NAME
+
pkgver=VERSION
+
pkgrel=1
+
pkgdesc=""
+
arch=('i686' 'x86_64')
+
url="http://ADDRESS/"
+
license=('GPL')
+
groups=()
+
depends=()
+
makedepends=()
+
optdepends=()
+
provides=()
+
conflicts=()
+
replaces=()
+
backup=()
+
options=()
+
install=
+
source=($pkgname-$pkgver.tar.gz)
+
noextract=()
+
md5sums=() #generate with 'makepkg -g'
+
build() {
+
 
   cd $srcdir/$pkgname-$pkgver
 
   cd $srcdir/$pkgname-$pkgver
 
   ./configure --prefix=/usr
 
   ./configure --prefix=/usr
   make || return 1
+
   make
  make DESTDIR=$pkgdir install || return 1
+
}
}
+
  
====Package Etiquette====
+
package() {
 +
  cd $srcdir/$pkgname-$pkgver
 +
  make DESTDIR=$pkgdir install
 +
}
 +
</pre>
 +
 
 +
Altri prototipi sono reperibili in /usr/share/pacman dai pacchetti di pacman e abs.
 +
 
 +
====Etichetta del pacchetto====
  
 
<ul>
 
<ul>
<li>Packages should <strong>never</strong> be installed to <code>/usr/local</code></li>
+
<li>I pacchetti non dovrebbero <strong>mai</strong> essere installati in <code>/usr/local</code></li>
<li>Where possible, use <code><strong>"|| return 1"</strong></code> in important build functions
+
<pre>patch -Np1 -i ../patchfile.patch || return 1
+
make || return 1
+
make DESTDIR=$pkgdir install || return 1
+
</pre>
+
 
<li>
 
<li>
<strong>Do not introduce new variables</strong> into
+
<strong>Non introdurre nuove variabili</strong> negli script di compilazione
your <code>PKGBUILD</code> build scripts, unless the package cannot be built without doing so, as these could
+
<code>PKGBUILD</code>, a meno che il pacchetto non possa essere compilato senza, dato che queste potrebbero
possibly <strong>conflict</strong> with variables used
+
generare dei <strong>conflitti</strong> con le variabili utilizzate
in makepkg itself.
+
in makepkg.
  
If a new variable is absolutely required,
+
Se una nuova variabile è assolutamente necessaria,
<strong>prefix the variable name with an underscore</strong> (<code>_</code>) e.g
+
<strong>sottolineare il nome della variabile</strong> (<code>_</code>), ad esempio:
 
<pre>_customvariable=</pre>
 
<pre>_customvariable=</pre>
  
The AUR cannot detect the use of custom variables and so cannot use them in substitutionsThis can most often be seen in the source array e.g.
+
AUR non può rilevare l'uso di variabili personalizzate e quindi non le può utilizzare per le sostituzioniLo si può osservare spesso, ad esempio in:
 
<pre>http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2</pre>
 
<pre>http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2</pre>
Such a situation defeats the effective functionality of the AUR.
+
Tale situazione contrasta con l'effettiva funzionalità di AUR.
 
</li>
 
</li>
  
 
<li>
 
<li>
<strong>Avoid</strong> using <code>/usr/libexec/</code> for
+
<strong>Evitare</strong> l'utilizzo di <code>/usr/libexec/</code> per
anything. Use <code>/usr/lib/${pkgname}/</code> instead.
+
nulla. Usare piuttosto <code>/usr/lib/${pkgname}/</code>.
 
</li>
 
</li>
 
<li>
 
<li>
The <code>packager</code> field from the package meta file can be
+
Il campo <code>packager</code> del file meta pacchetto può essere
<strong>customized</strong> by the package builder by modifying
+
<strong>personalizzato</strong> dal compilatore del pacchetto modificando
the appropriate option in the <code>/etc/makepkg.conf</code>
+
l'apposita opzione nel file <code>/etc/makepkg.conf</code>,
 +
 
 +
o in alternativa sovrascriverlo creando ~/.makepkg.conf
  
file, or alternatively by exporting the <code>PACKAGER</code>
 
environment variable before building packages with
 
<code>makepkg</code>:
 
<pre># export PACKAGER="John Doe@your.email"</pre>
 
 
</li>
 
</li>
<li>All
+
<li>Tutti i
important messages should be echoed during install using an <strong>.install file</strong>. For
+
messaggi importanti dovrebbero essere visualizzati (con echo) durante l'installazione utilizzando un file <strong>.install</strong>. Ad esempio, se un pacchetto ha bisogno di impostazioni extra per poter funzionare, tali indicazioni dovrebbero essere incluse. </li>
example, if a package needs extra setup to work, directions should be included. </li>
+
             <li>Qualsiasi <strong>dipendenza opzionale</strong> non richiesta necessariamente per eseguire il pacchetto o con funzioni generali non dovrebbe essere
             <li>Any <strong>optional dependencies</strong> that aren't
+
inclusa; l'informazione dovrebbe invece essere aggiunta all'array <b>optdepends</b>:
needed to run the package or have it generally function shouldn't be
+
included; instead the information should be added to the <b>optdepends</b> array:
+
 
<pre>
 
<pre>
 
optdepends=('cups: printing support'
 
optdepends=('cups: printing support'
Line 97: Line 100:
 
</pre>
 
</pre>
  
The above example is taken from the <b>wine</b> package in <tt>extra</tt>. The optdepends
+
L'esempio precedente è stato preso dal pacchetto <b>wine</b> in <tt>extra</tt>. Le informazioni "optdepends"
information will automatically be printed out on installation/upgrade from pacman 3.2.1, so
+
vengono automaticamente stampate durante l'installazione/aggiornamento perciò
one should <b>not</b> keep this kind of information in .install files any longer.
+
<b>non</b> si dovrebbe mettere questo tipo di informazioni nei file .install.
  
 
</li>
 
</li>
         <li>When creating a <strong>package description</strong> for a package, do not include
+
         <li>Quando si crea una <strong>descrizione del pacchetto</strong>, non includere
         the package name in a self-referencing way. For example, "Nedit is a text editor for X11" could be simplified to "A text editor for X11".  Also try to keep the descriptions to ~80 characters or less.</li>
+
         il nome del pacchetto in modo autoreferenziale. Per esempio, "Nedit è un editor di testo per X11" potrebbe essere semplificato con "Un editor di testo per X11".  Tentare anche di mantenere le descrizioni a ~80 caratteri o meno.</li>
<li>Try to keep the <strong>line length</strong> in the PKGBUILD below ~100 characters.</li>
+
<li>Tentare di mantenere inoltre la <strong>lunghezza della riga</strong> nel PKGBUILD al di sotto dei 100 caratteri.</li>
<li>Where possible, <strong>remove empty lines</strong> from the <code>PKGBUILD</code> (<code>provides</code>, <code>replaces</code>, etc.)</li>
+
<li>Laddove possibile, <strong>rimuovere le righe vuote</strong> dal <code>PKGBUILD</code> (<code>provides</code>, <code>replaces</code>, ecc.)</li>
<li>It is common practice to <strong>preserve the order</strong> of the <code>PKGBUILD</code> fields as shown above. However, this is not mandatory, as the only requirement in this context is <strong>correct bash syntax</strong>.</li>
+
<li>È pratica comune <strong>preservare l'ordine</strong> dei campi <code>PKGBUILD</code> come indicato sopra. Tuttavia, questo non è obbligatorio, in quanto l'unico requisito in questo contesto è la <strong>corretta sintassi bash</strong>.</li>
 
</ul>
 
</ul>
  
====Package Naming====
+
====Denominazione pacchetto====
 
 
 
<ul>
 
<ul>
 
<li>
 
<li>
Package names should consist of <strong>alphanumeric characters
+
I nomi del pacchetto devono essere composti solo da <strong>caratteri alfanumerici</strong>; tutte le lettere devono essere
only</strong>; all letters should be
+
<strong>minuscole</strong>.
<strong>lowercase</strong>.
+
 
</li>
 
</li>
 
<li>
 
<li>
Package versions <strong>should be the same as the version
+
Le versioni del pacchetto <strong>dovrebbero essere la stessa della versione rilasciata dall'autore</strong>. Le versioni possono comprendere lettere, se necessario (ad esempio, la versione nmap è 2.54BETA32).
released by the author</strong>. Versions can include
+
<strong>I tag della versione non dovrebbero includere trattini!</strong>, ma solo lettere, numeri e punti.
letters if need be (eg, nmap's version is 2.54BETA32).
+
<strong>Version tags may not include hyphens!</strong> Letters,
+
numbers, and periods only.
+
 
</li>
 
</li>
  
 
<li>
 
<li>
Package releases are <strong>specific to Arch Linux
+
Le release dei pacchetti sono <strong>specifiche per i pacchetti Arch Linux</strong>.  
packages</strong>. These allow users to differentiate
+
                Queste permettono agli utenti di distinguere le build del pacchetto nuove dalle vecchie.  
between newer and older package builds. When a new package
+
                Quando viene rilasciata una nuova versione del pacchetto, il <strong>conto della release  
version is first released, the <strong>release count starts at
+
                parte da 1</strong>. Poi, quando vengono eseguite correzioni ed ottimizzazioni,
1</strong>. Then as fixes and optimizations are made,
+
il pacchetto viene <strong>rilasciato</strong> nuovamente all'utenza di Arch Linux ed
the package will be <strong>re-released</strong> to the AL
+
                il <strong>numero di release verrà incrementato</strong>. Quando esce una nuova versione,
public and the <strong>release number will increment</strong>.
+
                il conteggio del rilascio viene azzerato a 1. Il tag del rilascio dei pacchetti segue le
When a new version comes out, the release count resets to 1.
+
                <strong>stesse limitazioni di nominazione che i tag di versione</strong>.
Package release tags follow the <strong>same naming
+
restrictions as version tags</strong>.
+
 
</li>
 
</li>
 
</ul>
 
</ul>
  
<h4>Directories</h4>
+
<h4>Directory</h4>
 
<ul>
 
<ul>
 
<li>
 
<li>
<strong>Configuration files</strong> should be placed in the
+
<strong>I file di configurazione</strong> dovrebbero essere messi nella directory <code>/etc</code>. Se c'è più di un file di configurazione, è consuetudine <strong>utilizzare una sottodirectory</strong> in modo da mantenere <code>/etc</code> il più pulita possibile. Utilizzare
<code>/etc</code> directory. If there's more than one
+
<code>/etc/{pkgname}/</code>, dove <code>{pkgname}</code> è il nome del pacchetto (oppure un'alternativa valida, per esempio apache
configuration file, it's customary to <strong>use a
+
usa <code>/etc/httpd/</code>).
subdirectory</strong> in order to keep the
+
<code>/etc</code> area as clean as possible. Use
+
<code>/etc/{pkgname}/</code> where <code>{pkgname}</code> is
+
the name of your package (or a suitable alternative, eg, apache
+
uses <code>/etc/httpd/</code>).
+
 
</li>
 
</li>
  
 
<li>
 
<li>
Package files should follow these
+
I pacchetti dovrebbero seguire queste
<strong>general directory guidelines</strong>:
+
<strong>linee guida delle directory generali</strong>:
 
</li>
 
</li>
 
 
Line 161: Line 153:
 
<td><code>/etc</code></td>
 
<td><code>/etc</code></td>
 
<td style="padding-left: 1em;">
 
<td style="padding-left: 1em;">
<strong>System-essential</strong> configuration files
+
<strong>File essenziali</strong> di configurazione del sistema
 
</td>
 
</td>
 
</tr>
 
</tr>
 
<tr>
 
<tr>
 
<td><code>/usr/bin</code></td>
 
<td><code>/usr/bin</code></td>
<td style="padding-left: 1em;">Application binaries</td>
+
<td style="padding-left: 1em;">Applicazioni binarie</td>
 
</tr>
 
</tr>
 
<tr>
 
<tr>
 
<td><code>/usr/sbin</code></td>
 
<td><code>/usr/sbin</code></td>
  
<td style="padding-left: 1em;">System binaries</td>
+
<td style="padding-left: 1em;">Binari di sistema</td>
 
</tr>
 
</tr>
 
<tr>
 
<tr>
 
<td><code>/usr/lib</code></td>
 
<td><code>/usr/lib</code></td>
<td style="padding-left: 1em;">Libraries</td>
+
<td style="padding-left: 1em;">Librerie</td>
 
</tr>
 
</tr>
 
<tr>
 
<tr>
 
<td><code>/usr/include</code></td>
 
<td><code>/usr/include</code></td>
<td style="padding-left: 1em;">Header files</td>
+
<td style="padding-left: 1em;">Header file</td>
 
</tr>
 
</tr>
 
<tr>
 
<tr>
 
<td><code>/usr/lib/{pkg}</code></td>
 
<td><code>/usr/lib/{pkg}</code></td>
<td style="padding-left: 1em;">Modules, plugins, etc.</td>
+
<td style="padding-left: 1em;">Moduli, plugin, ecc.</td>
 
</tr>
 
</tr>
 
<tr>
 
<tr>
 
<td><code>/usr/share/doc/{pkg}</code></td>
 
<td><code>/usr/share/doc/{pkg}</code></td>
<td style="padding-left: 1em;">Application documentation</td>
+
<td style="padding-left: 1em;">Documentazione delle applicazioni</td>
 
</tr>
 
</tr>
 
<tr>
 
<tr>
 
<td><code>/usr/share/info</code></td>
 
<td><code>/usr/share/info</code></td>
<td style="padding-left: 1em;">GNU Info system files</td>
+
<td style="padding-left: 1em;">Informazioni file di sistema</td>
 
</tr>
 
</tr>
 
<tr>
 
<tr>
 
<td><code>/usr/share/man</code></td>
 
<td><code>/usr/share/man</code></td>
<td style="padding-left: 1em;">Manpages</td>
+
<td style="padding-left: 1em;">Pagine di manuale</td>
 
</tr>
 
</tr>
 
<tr>
 
<tr>
 
<td><code>/usr/share/{pkg}</code></td>
 
<td><code>/usr/share/{pkg}</code></td>
<td style="padding-left: 1em;">Application data</td>
+
<td style="padding-left: 1em;">Dati delle applicazioni</td>
 
</tr>
 
</tr>
 
<tr>
 
<tr>
 
<td><code>/var/lib/{pkg}</code></td>
 
<td><code>/var/lib/{pkg}</code></td>
<td style="padding-left: 1em;">Persistent application storage</td>
+
<td style="padding-left: 1em;">Memorizzazione applicazioni persistenti</td>
 
</tr>
 
</tr>
 
<tr>
 
<tr>
 
<td><code>/etc/{pkg}</code></td>
 
<td><code>/etc/{pkg}</code></td>
<td style="padding-left: 1em;">Configuration files for <code>{pkg}</code></td>
+
<td style="padding-left: 1em;">File di configurazione per <code>{pkg}</code></td>
 
</tr>
 
</tr>
 
<tr>
 
<tr>
 
<td><code>/opt/{pkg}</code></td>
 
<td><code>/opt/{pkg}</code></td>
 
<td style="padding-left: 1em;">
 
<td style="padding-left: 1em;">
Large self-contained packages such as Java,
+
Pacchetti autonomi grandi, come Java,
etc.
+
ecc.
 
</td>
 
</td>
 
</tr>
 
</tr>
Line 219: Line 211:
  
 
<li>
 
<li>
Package should not contain following directories:
+
Il pacchetto non dovrebbe contenere le seguenti directory:
 
<ul>
 
<ul>
 
<li>/dev
 
<li>/dev
Line 237: Line 229:
 
</ul>
 
</ul>
  
====[[Makepkg]] Duties====
+
====Compiti di [[Makepkg]]====
  
 
<p>
 
<p>
When you use makepkg to build a package for you, it does the
+
Quando si utilizza makepkg per la compilazione di un pacchetto, quello che fa automaticamente è:
following automatically:
+
 
</p>
 
</p>
  
 
<ol>
 
<ol>
 
<li>
 
<li>
Checks if package <strong>dependencies</strong> and <strong>makedepends</strong> are installed
+
Verificare che i pacchetti <strong>dependencies</strong> e <strong>makedepends</strong> siano installati
 
</li>
 
</li>
 
<li>
 
<li>
<strong>Downloads source</strong> files from servers
+
<strong>Scaricare i sorgenti</strong> dai server
 
</li>
 
</li>
 
<li>
 
<li>
<strong>Checks the integrity</strong> of source files
+
<strong>Verificare l'integrità</strong> dei file sorgente
 
</li>
 
</li>
 
<li>
 
<li>
<strong>Unpacks</strong> source files
+
<strong>Decomprimere</strong> i file sorgente
 
</li>
 
</li>
 
<li>
 
<li>
Does any necessary <strong>patching</strong>
+
Eseguire tutte le operazioni necessarie di <strong>patching</strong>
 
</li>
 
</li>
 
<li>
 
<li>
  
<strong>Builds</strong> the software and installs it in a fake
+
<strong>Compilare</strong> il software e lo installa in una directory fake root
root
+
 
</li>
 
</li>
 
<li>
 
<li>
<strong>Strips</strong> symbols from binaries
+
<strong>Rimuovere</strong> i simboli dai binari
 
</li>
 
</li>
 
<li>
 
<li>
<strong>Strips</strong> debugging symbols from libraries
+
<strong>Rimuovere</strong> i simboli di debug dalle librerie
 
</li>
 
</li>
 
<li>
 
<li>
<strong>Compresses</strong> manual and, or info pages
+
<strong>Comprimere</strong> i manuali e/o le pagine info
 
</li>
 
</li>
 
<li>
 
<li>
Generates the <strong>package meta file</strong> which is
+
Generare il <strong>file meta pacchetto</strong> che è incluso in ogni pacchetto
included with each package
+
 
</li>
 
</li>
  
 
<li>
 
<li>
<strong>Compresses</strong> the fake root into the package file
+
<strong>Comprimere</strong> la fake root nel pacchetto
 
</li>
 
</li>
 
<li>
 
<li>
<strong>Stores</strong> the package file in the configured
+
<strong>Memorizzare</strong> i file del pacchetto nella directory di destinazione configurata
destination directory
+
(<span title="Current Working Directory" style="border-bottom:1px dotted">cwd</span> è quella di
(<span title="Current Working Directory" style="border-bottom:1px dotted">cwd</span> by
+
 
default)
 
default)
 
</li>
 
</li>
Line 291: Line 279:
 
</ol>
 
</ol>
  
====Architectures====
+
====Architetture====
The <tt>arch</tt> array should contain <tt>'i686'</tt> and/or <tt>'x86_64'</tt> depending on which architectures it can be built on. You can also use <tt>'any'</tt> for architecture independent packages.
+
L'array <tt>arch</tt> dovrebbe contenere <tt>"i686"</tt> e/o <tt>"x86_64"</tt> a seconda di qual è l'architettura di destinazione. È inoltre possibile utilizzare <tt>"any"</tt> per i pacchetti idonei ad entrambi i tipi di architettura.
  
====Licenses====
+
====[[Licenses]]====
The license array is being implemented little by little in the official repos, and it <b>should</b> be used in your packages as well. You can use it as follows:
+
L'array della licenza è in corso di implementazione nei repo ufficiali, e <b>dovrebbe</b> essere utilizzato pure nei propri pacchetti. Specificare come segue:
 
<ul>
 
<ul>
<li>A licenses package has been created in [core] that stores common licenses in /usr/share/licenses/common ie. /usr/share/licenses/common/GPL.  If a package is licensed under one of these licenses, the licenses variable will be set to the directory name e.g. license=('GPL')</li>
+
<li>Un pacchetto licenze è stato creato in [core] e contiene licenze comuni in /usr/share/licenses/common, ad esempio /usr/share/licenses/common/GPL.  Se un pacchetto è rilasciato sotto una di queste licenze, la variabile licenze dovrà essere impostata con il nome della directory, ad esempio license=("GPL")</li>
<li>If the appropriate license is not included in the official licenses package, several things must be done:
+
<li>Se la licenza appropriata non è inclusa nel pacchetto licenze ufficiali, si dovranno fare diverse altre cose:
 
<ol>
 
<ol>
<li>The license file(s) should be included in /usr/share/licenses/$pkgname/ e.g. /usr/share/licenses/dibfoo/COPYING.</li>
+
<li>I file delle licenze dovrebbero essere inclusi in /usr/share/licenses/$pkgname/, ad esempio /usr/share/licenses/dibfoo/LICENSE. Un buon modo per farlo è tramite:
<li>If the source tarball does NOT contain the license details and the license is only displayed on a website for example, then you need to copy the license to a file and include it. Remember to call it something appropriate too.
+
<pre>install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"</pre>
<li>Add 'custom' to the licenses array.  Optionally, you can replace 'custom' with 'custom:"name of license"'.</li>
+
</li>
 +
<li>Se l'archivio dei sorgenti non contiene i dettagli della licenza, ma la si può ad esempio visualizzare su un sito web, copiarla in un file e inserirla. Ricordarsi anche di nominarla in modo appropriato.
 +
<li>Aggiungere "custom" all'array licenzeOpzionalmente, è possibile sostituire "custom" con custom:"name of license".</li>
 
</ol></li>
 
</ol></li>
<li>Once a licenses is used in two or more packages in an official repo, including [community], it becomes common</li>
+
<li>Una volta che viene utilizzata una licenza in due o più pacchetti in un repo ufficiale, incluso [community], diviene "common"</li>
<li>The MIT, BSD, zlib/libpng and Python licenses are special cases and cannot be included in the 'common' licenses pkgFor the sake of the license variable, it's treated like a common license (license=('BSD'), license=('MIT'), license=('ZLIB') or license=('Python')) but for the sake of the filesystem, it's a custom license, because each one has its own copyright lineEach MIT, BSD, zlib/libpng or Python licensed package should have its unique license stored in /usr/share/licenses/$pkgname/.</li>
+
<li>Le licenze MIT, BSD, zlib/libpng e Python sono casi particolari e non possono essere incluse nel pacchetto "common license"A causa della variabile della licenza, è trattata come una licenza comune (license=('BSD'), license=('MIT'), license=('ZLIB') or license=('Python')) ma per il bene del filesystem, è una licenza personalizzata, perché ognuno ha una propria linea di diritto d'autoreOgni pacchetto licenze MIT, BSD, zlib/libpng o Python dovrebbe avere la propria licenza unica conservata in /usr/share/licenses/$pkgname/.</li>
<li>Some packages may not be covered by a single license.  In these cases multiple entries may be made in the license array e.g. license=("GPL" "custom:some commercial license").  For the majority of packages these licenses apply in different cases, as opposed to applying at the same timeWhen pacman gets the ability to filter on licenses (so you can say, "I only want GPL and BSD licensed software") dual (or more) licenses will be treated by pacman using OR, rather than AND logic, thus pacman will consider the above example as GPL licensed software, regardless of the other licenses listed.</li>
+
<li>Alcuni pacchetti non possono essere oggetto di una singola licenza.  In questi casi possono essere immesse più voci nell'array licenza, per esempio license=("GPL" "custom:some commercial license").  Per la maggior parte dei pacchetti queste licenze si applicano in diversi casi, invece di applicarle allo stesso tempoUna volta che a pacman sarà aggiuntà la possibilità di filtrare i risultati in base alle licenze (in modo da poter scegliere ad esempio: "voglio solo software rilasciato sotto licenze BSD e GPL"), software rilasciati sotto licenze duplici (o multiple) saranno trattati da pacman con logica OR piuttosto che AND, in modo che pacman prenda in considerazione nell'esempio succitato tutti i software rilasciati almeno sotto una delle due licenze GPL e BSD, tralasciando tutti gli altri.</li>
<li>The (L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:
+
<li>La (L)GPL ha molte versioni e permutazioni di tali versioni. Per il software (L)GPL, la convenzione è:
 
<ul>
 
<ul>
<li>(L)GPL - (L)GPLv2 or any later version</li>
+
<li>(L)GPL - (L)GPLv2 od ogni versione successiva</li>
<li>(L)GPL2 - (L)GPL2 only</li>
+
<li>(L)GPL2 - (L)GPL2 solo</li>
<li>(L)GPL3 - (L)GPL3 or any later version</li>
+
<li>(L)GPL3 - (L)GPL3 od ogni versione successiva</li>
 
</ul>
 
</ul>
 
</li>
 
</li>
 
</ul>
 
</ul>
  
====Submitting Packages to the AUR====
+
====Invio di pacchetti ad AUR====
<p>Note the following before submitting any packages to the AUR:</p>
+
<p>Si osservino le seguenti specifiche prima di inviare qualsiasi pacchetto ad AUR:</p>
  
 
<ol>
 
<ol>
 
         <li>
 
         <li>
                 The submitted PKGBUILDs <strong>MUST NOT</strong> build applications already in any of the official binary repositories under any circumstances. Exception to this strict rule may only be packages having extra features enabled and/or patches in compare to the official ones. In such an occasion the pkgname array should be different to express that difference.
+
                 I PKGBUILD inviati <strong>NON</strong> devono assolutamente essere già presenti in nessuno dei repository binari ufficiali. L'unica eccezione a questa rigorosa regola può essere solo quella di pacchetti con caratteristiche o funzionalità extra, e/o con eventuali patch che li contraddistinguono da quelli ufficiali. In tali occasioni l'array pkgname dovrebbe essere diverso per specificare queste differenze.
eg. A GNU screen PKGBUILD submitted containing the sidebar patch, could be named screen-sidebar etc. Additionally the <strong>provides=('screen')</strong> PKGBUILD array should be used in order to avoid conflicts with the official package.
+
Esempio: Un PKGBUILD con uno schermo GNU inviato con la patch sidebar, potrebbe essere chiamato screen-sidebar ecc. Inoltre, l'array del PKGBUILD <strong>provides=('screen')</strong> dovrebbe essere utilizzato al fine di evitare conflitti con il pacchetto ufficiale.
 
         </li>
 
         </li>
 
<li>
 
<li>
To ensure the security of pkgs submitted to the AUR please <strong>ensure</strong> that you have correctly filled the <code>md5sum</code> fieldThe <code>md5sum</code>'s can be generated using the <code>makepkg -g</code> command.
+
Per garantire la sicurezza dei pacchetti inviati ad AUR si prega di <strong>verificare</strong> di aver compilato correttamente il campo <code>md5sum</code>.  L'<code>md5sum</code> può essere generato utilizzando il comando <code>makepkg -g</code>.
 
</li>
 
</li>
 
<li>
 
<li>
Please <strong>add a comment line</strong> to the top of your
+
Si prega di <strong>aggiungere una riga di commento</strong> nella parte superiore del file
<code>PKGBUILD</code> file that follows this formatRemember to disguise
+
<code>PKGBUILD</code> che segue questo formatoRicordarsi di mascherare
                your email to protect against spam:
+
                il proprio indirizzo e-mail per evitare lo spam:
  
 
<pre># Maintainer: Your Name <address at domain dot com></pre>
 
<pre># Maintainer: Your Name <address at domain dot com></pre>
  
If you are assuming the role of maintainer for an existing PKGBUILD, add your name to the top as described above and change the title of the previous Maintainer(s) to Contributor:
+
Se si sta assumendo il ruolo di manutentore di un PKGBUILD esistente, aggiungere il proprio nome in cima come descritto sopra e cambiare il titolo del precedente Maintainer a Contributor:
  
 
<pre># Maintainer: Your Name <address at domain dot com>
 
<pre># Maintainer: Your Name <address at domain dot com>
Line 341: Line 331:
 
</li>
 
</li>
 
<li>
 
<li>
Verify the package <strong>dependencies</strong> (eg, run
+
Verificare le <strong>dipendenze</strong> del pacchetto (ad esempio, eseguire
<code>ldd</code> on dynamic executables, check tools required
+
<code>ldd</code> su eseguibili dinamici, controllare i tool richiesti
by scripts, etc).
+
dagli script, ecc).
  
The TU team <strong>strongly</strong> recommend the use of the
+
I TU raccomandano <strong>vivamente</strong> l'utilizzo dell'utilità
<code>namcap</code> utility, written by Jason Chu (jason@archlinux.org), to analyze the
+
<code>namcap</code>, elaborato da Jason Chu (jason@archlinux.org), per analizzare lo stato
sanity of your package. <code>namcap</code> will tell you about
+
dei pacchetti. <code>Namcap</code> avviserà riguardo
bad permissions, missing dependencies, un-needed dependencies,
+
permessi errati, dipendenze mancanti, dipendenze non richieste,
and other common mistakes. You can install the
+
ed altri errori comuni. Si può installare il pacchetto
<code>namcap</code> package with <code>pacman</code>.
+
<code>namcap</code> con <code>pacman</code>.
  
Remember <code>namcap</code> can be used to check both pkg.tar.gz files and PKGBUILDs
+
Ricordare inoltre che <code>namcap</code> può essere usato per controllare sia file pkg.tar.gz che PKGBUILD.
 
</li>
 
</li>
<li> <strong>Dependencies</strong>
+
<li> Le <strong>dipendenze</strong>
are the most common packaging error. Namcap can help detect them, but
+
sono tra gli errori più comuni riguardo la pacchettizzazione. Namcap può aiutare a rilevarle, ma
it is not always correct. Verify dependencies by looking at source
+
non è sempre infallibile. Verificare le dipendenze consultando la documentazione dei sorgenti e il sito web del programma. </li>
documentation and the program website. </li>
+
<li>'''Non utilizzare <tt>replaces</tt>''' in un PKGBUILD a meno che il pacchetto debba essere rinominato, per esempio quando ''Ethereal'' diventa ''Wireshark''. Se il pacchetto è una versione alternativa di un pacchetto già esistente, usare <tt>conflicts</tt> (e <tt>provides</tt> se tale pacchetto è richiesto da altri). La differenza principale è che dopo la sincronizzazione (-Sy), pacman vuole subito sostituire il pacchetto installato, per trovare un pacchetto con il "matching" <tt>replaces</tt> da qualche parte nei suoi repository; <tt>conflicts</tt> d'altra parte viene considerato solo quando ha effettivamente luogo l'installazione del pacchetto, che di solito è il comportamento desiderato, dato che è meno invasivo.</li>
<li>'''Don't use <tt>replaces</tt>''' in your PKGBUILD unless you want to rename your package, for example when ''Ethereal'' became ''Wireshark''. If you just provide an alternate version of an already existing package, use <tt>conflicts</tt> (and <tt>provides</tt> if that package is required by others). The main difference is: after syncing (-Sy) pacman immediately wants to replace an installed, 'offending' package upon encountering a package with the matching <tt>replaces</tt> anywhere in its repositories; <tt>conflicts</tt> on the other hand is only evaluated when actually installing the package, which is pretty much always the desired behavior because you don't push your package down other people's throat this way.</li>
+
 
<li>
 
<li>
All files uploaded to the AUR should be contained in a <strong>compressed tar
+
Tutti i file caricati su AUR devono essere contenuti in un <strong>file tar compresso
file</strong> containing a directory with the <strong><code>PKGBUILD</code></strong> and <strong>additional build files</strong> (patches, install, ...) in it.
+
</strong> contenente una directory con il <strong><code>PKGBUILD</code></strong> e i <strong>file di compilazione aggiuntivi</strong> (patch, install, ...).
 
<pre>foo/PKGBUILD
 
<pre>foo/PKGBUILD
 
foo/foo.install
 
foo/foo.install
 
foo/foo_bar.diff
 
foo/foo_bar.diff
 
foo/foo.rc.conf</pre>
 
foo/foo.rc.conf</pre>
The archive name should contain the name of the package
+
Il nome dell'archivio dovrebbe contenere il nome del pacchetto,
e.g. foo.tar.gz.
+
ad esempio foo.tar.gz.
  
You can easily build a tarball containing all the required files by using <tt>makepkg --source</tt>. This
+
Si può facilmente compilare un archivio contenente tutti i file richiesti utilizzando <tt>makepkg --source</tt>. Questo
makes a tarball named <tt>$pkgname-$pkgver-$pkgrel.src.tar.gz</tt>, which you can then upload to the AUR.
+
rinominerà un tarball <tt>$pkgname-$pkgver-$pkgrel.src.tar.gz</tt>, che può essere poi caricato su AUR.
 
 
The tarball <strong>should not</strong> contain the binary tarball created by makepkg, nor should it contain the filelist
+
Il tarball <strong>non dovrebbe</strong> contenere nè il tarball binario creato da makepkg, né la filelist.
 
</li>
 
</li>
  
 
</ol>
 
</ol>
  
==Additional Guidelines==
+
==Linee guida supplementari==
Be sure to read the above guidelines first - important points are listed on this page that will not be repeated in the following guideline pages.  These specific guidelines are intended as an addition to the standards listed on this page.
+
Si raccomanda di leggere per prima cosa le linee guida descritte sopra: molti concetti importanti sono spiegati in questa pagina e non verranno ripetuti nelle seguenti guide specifiche, che sono intese come un complemento agli standard elencati in questa pagina.
  
 
<h4>CVS/SVN Packages</h4>
 
<h4>CVS/SVN Packages</h4>
Please see the [[Arch CVS & SVN PKGBUILD guidelines]]
+
Si prega di consultare [[Arch CVS & SVN PKGBUILD guidelines]]
  
 
<h4>Eclipse Plugin Packages</h4>
 
<h4>Eclipse Plugin Packages</h4>
Please see the [[Eclipse plugin package guidelines]]
+
Si prega di consultare [[Eclipse plugin package guidelines]]
  
 
         <h4>Gnome Packages</h4>
 
         <h4>Gnome Packages</h4>
Please see the [[Gnome package guidelines]]
+
Si prega di consultare [[Gnome package guidelines]]
  
 
<h4>Haskell Packages</h4>
 
<h4>Haskell Packages</h4>
Please see the [[Haskell package guidelines]]
+
Si prega di consultare [[Haskell package guidelines]]
  
 
<h4>Java Packages</h4>
 
<h4>Java Packages</h4>
Please see the [[Java Package Guidelines]]
+
Si prega di consultare [[Java Package Guidelines]]
  
 
         <h4>Kernel Module Packages</h4>
 
         <h4>Kernel Module Packages</h4>
Please see the [[Kernel Module Package Guidelines]]
+
Si prega di consultare [[Kernel Module Package Guidelines]]
  
 
         <h4>Lisp Packages</h4>
 
         <h4>Lisp Packages</h4>
Please see the [[Lisp Package Guidelines]]
+
Si prega di consultare [[Lisp Package Guidelines]]
 +
 
 +
        <h4>OCaml Packages</h4>
 +
Si prega di consultare [[OCaml_Package_Guidelines]]
  
 
         <h4>Perl Packages</h4>
 
         <h4>Perl Packages</h4>
Please see the [[Perl Package Guidelines]]
+
Si prega di consultare [[Perl Package Guidelines]]
  
 
         <h4>Python Packages</h4>
 
         <h4>Python Packages</h4>
Please see the [[Python Package Guidelines]]
+
Si prega di consultare [[Python Package Guidelines]]
  
 
         <h4>Ruby Gem Packages</h4>
 
         <h4>Ruby Gem Packages</h4>
Please see the [[Ruby Gem Package Guidelines]]
+
Si prega di consultare [[Ruby Gem Package Guidelines]]
  
 
         <h4>Wine Packages</h4>
 
         <h4>Wine Packages</h4>
Please see the [[Arch wine PKGBUILD guidelines]]
+
Si prega di consultare [[Arch wine PKGBUILD guidelines]]

Revision as of 02:28, 25 October 2012

Standard di Pacchettizzazione

I PKGBUILD messi su AUR dagli utenti NON DEVONO riferirsi ad applicazioni già presenti nei repository ufficiali in nessuna circostanza. Eccezione a questa regola sono quei pacchetti compilati con particolari funzionalità abilitate e/o patch applicate differenti da quelle dei pacchetti ufficiali. In questi casi, la voce pkgname deve essere differente, in modo da comunicare chiaramente le differenze dai pacchetti presenti nei repo.

Nella realizzazione di pacchetti per Arch Linux, si dovrebbe aderire alle linee guida per la pacchettizzazione elencate qui sotto, soprattutto se avete intenzione di caricare il vostro PKGBUILD su AUR. Fare riferimento inoltre alle pagine di manuale di PKGBUILD e di makepkg.

Prototipo di PKGBUILD

# Maintainer: Your Name <youremail at domain dot com>

pkgname=NAME
pkgver=VERSION
pkgrel=1
pkgdesc=""
arch=('i686' 'x86_64')
url="http://ADDRESS/"
license=('GPL')
groups=()
depends=()
makedepends=()
optdepends=()
provides=()
conflicts=()
replaces=()
backup=()
options=()
install=
source=($pkgname-$pkgver.tar.gz)
noextract=()
md5sums=() #generate with 'makepkg -g'

build() {
  cd $srcdir/$pkgname-$pkgver
  ./configure --prefix=/usr
  make
}

package() {
  cd $srcdir/$pkgname-$pkgver
  make DESTDIR=$pkgdir install
}

Altri prototipi sono reperibili in /usr/share/pacman dai pacchetti di pacman e abs.

Etichetta del pacchetto

  • I pacchetti non dovrebbero mai essere installati in /usr/local
  • Non introdurre nuove variabili negli script di compilazione PKGBUILD, a meno che il pacchetto non possa essere compilato senza, dato che queste potrebbero generare dei conflitti con le variabili utilizzate in makepkg. Se una nuova variabile è assolutamente necessaria, sottolineare il nome della variabile (_), ad esempio:
    _customvariable=

    AUR non può rilevare l'uso di variabili personalizzate e quindi non le può utilizzare per le sostituzioni. Lo si può osservare spesso, ad esempio in:

    http://downloads.sourceforge.net/directxwine/$patchname.$patchver.diff.bz2

    Tale situazione contrasta con l'effettiva funzionalità di AUR.

  • Evitare l'utilizzo di /usr/libexec/ per nulla. Usare piuttosto /usr/lib/${pkgname}/.
  • Il campo packager del file meta pacchetto può essere personalizzato dal compilatore del pacchetto modificando l'apposita opzione nel file /etc/makepkg.conf, o in alternativa sovrascriverlo creando ~/.makepkg.conf
  • Tutti i messaggi importanti dovrebbero essere visualizzati (con echo) durante l'installazione utilizzando un file .install. Ad esempio, se un pacchetto ha bisogno di impostazioni extra per poter funzionare, tali indicazioni dovrebbero essere incluse.
  • Qualsiasi dipendenza opzionale non richiesta necessariamente per eseguire il pacchetto o con funzioni generali non dovrebbe essere inclusa; l'informazione dovrebbe invece essere aggiunta all'array optdepends:
    optdepends=('cups: printing support'
                'sane: scanners support'
                'libgphoto2: digital cameras support'
                'alsa-lib: sound support'
                'giflib: GIF images support'
                'libjpeg: JPEG images support'
                'libpng: PNG images support')
    

    L'esempio precedente è stato preso dal pacchetto wine in extra. Le informazioni "optdepends" vengono automaticamente stampate durante l'installazione/aggiornamento perciò non si dovrebbe mettere questo tipo di informazioni nei file .install.

  • Quando si crea una descrizione del pacchetto, non includere il nome del pacchetto in modo autoreferenziale. Per esempio, "Nedit è un editor di testo per X11" potrebbe essere semplificato con "Un editor di testo per X11". Tentare anche di mantenere le descrizioni a ~80 caratteri o meno.
  • Tentare di mantenere inoltre la lunghezza della riga nel PKGBUILD al di sotto dei 100 caratteri.
  • Laddove possibile, rimuovere le righe vuote dal PKGBUILD (provides, replaces, ecc.)
  • È pratica comune preservare l'ordine dei campi PKGBUILD come indicato sopra. Tuttavia, questo non è obbligatorio, in quanto l'unico requisito in questo contesto è la corretta sintassi bash.

Denominazione pacchetto

  • I nomi del pacchetto devono essere composti solo da caratteri alfanumerici; tutte le lettere devono essere minuscole.
  • Le versioni del pacchetto dovrebbero essere la stessa della versione rilasciata dall'autore. Le versioni possono comprendere lettere, se necessario (ad esempio, la versione nmap è 2.54BETA32). I tag della versione non dovrebbero includere trattini!, ma solo lettere, numeri e punti.
  • Le release dei pacchetti sono specifiche per i pacchetti Arch Linux. Queste permettono agli utenti di distinguere le build del pacchetto nuove dalle vecchie. Quando viene rilasciata una nuova versione del pacchetto, il conto della release parte da 1. Poi, quando vengono eseguite correzioni ed ottimizzazioni, il pacchetto viene rilasciato nuovamente all'utenza di Arch Linux ed il numero di release verrà incrementato. Quando esce una nuova versione, il conteggio del rilascio viene azzerato a 1. Il tag del rilascio dei pacchetti segue le stesse limitazioni di nominazione che i tag di versione.

Directory

  • I file di configurazione dovrebbero essere messi nella directory /etc. Se c'è più di un file di configurazione, è consuetudine utilizzare una sottodirectory in modo da mantenere /etc il più pulita possibile. Utilizzare /etc/{pkgname}/, dove {pkgname} è il nome del pacchetto (oppure un'alternativa valida, per esempio apache usa /etc/httpd/).
  • I pacchetti dovrebbero seguire queste linee guida delle directory generali:
  • /etc

    File essenziali di configurazione del sistema

    /usr/bin Applicazioni binarie
    /usr/sbin Binari di sistema
    /usr/lib Librerie
    /usr/include Header file
    /usr/lib/{pkg} Moduli, plugin, ecc.
    /usr/share/doc/{pkg} Documentazione delle applicazioni
    /usr/share/info Informazioni file di sistema
    /usr/share/man Pagine di manuale
    /usr/share/{pkg} Dati delle applicazioni
    /var/lib/{pkg} Memorizzazione applicazioni persistenti
    /etc/{pkg} File di configurazione per {pkg}
    /opt/{pkg}

    Pacchetti autonomi grandi, come Java, ecc.

  • Il pacchetto non dovrebbe contenere le seguenti directory:
    • /dev
    • /home
    • /srv
    • /media
    • /mnt
    • /proc
    • /root
    • /selinux
    • /sys
    • /tmp
    • /var/tmp

Compiti di Makepkg

Quando si utilizza makepkg per la compilazione di un pacchetto, quello che fa automaticamente è:

  1. Verificare che i pacchetti dependencies e makedepends siano installati
  2. Scaricare i sorgenti dai server
  3. Verificare l'integrità dei file sorgente
  4. Decomprimere i file sorgente
  5. Eseguire tutte le operazioni necessarie di patching
  6. Compilare il software e lo installa in una directory fake root
  7. Rimuovere i simboli dai binari
  8. Rimuovere i simboli di debug dalle librerie
  9. Comprimere i manuali e/o le pagine info
  10. Generare il file meta pacchetto che è incluso in ogni pacchetto
  11. Comprimere la fake root nel pacchetto
  12. Memorizzare i file del pacchetto nella directory di destinazione configurata (cwd è quella di default)

Architetture

L'array arch dovrebbe contenere "i686" e/o "x86_64" a seconda di qual è l'architettura di destinazione. È inoltre possibile utilizzare "any" per i pacchetti idonei ad entrambi i tipi di architettura.

Licenses

L'array della licenza è in corso di implementazione nei repo ufficiali, e dovrebbe essere utilizzato pure nei propri pacchetti. Specificare come segue:

  • Un pacchetto licenze è stato creato in [core] e contiene licenze comuni in /usr/share/licenses/common, ad esempio /usr/share/licenses/common/GPL. Se un pacchetto è rilasciato sotto una di queste licenze, la variabile licenze dovrà essere impostata con il nome della directory, ad esempio license=("GPL")
  • Se la licenza appropriata non è inclusa nel pacchetto licenze ufficiali, si dovranno fare diverse altre cose:
    1. I file delle licenze dovrebbero essere inclusi in /usr/share/licenses/$pkgname/, ad esempio /usr/share/licenses/dibfoo/LICENSE. Un buon modo per farlo è tramite:
      install -D -m644 LICENSE "${pkgdir}/usr/share/licenses/${pkgname}/LICENSE"
    2. Se l'archivio dei sorgenti non contiene i dettagli della licenza, ma la si può ad esempio visualizzare su un sito web, copiarla in un file e inserirla. Ricordarsi anche di nominarla in modo appropriato.
    3. Aggiungere "custom" all'array licenze. Opzionalmente, è possibile sostituire "custom" con custom:"name of license".
  • Una volta che viene utilizzata una licenza in due o più pacchetti in un repo ufficiale, incluso [community], diviene "common"
  • Le licenze MIT, BSD, zlib/libpng e Python sono casi particolari e non possono essere incluse nel pacchetto "common license". A causa della variabile della licenza, è trattata come una licenza comune (license=('BSD'), license=('MIT'), license=('ZLIB') or license=('Python')) ma per il bene del filesystem, è una licenza personalizzata, perché ognuno ha una propria linea di diritto d'autore. Ogni pacchetto licenze MIT, BSD, zlib/libpng o Python dovrebbe avere la propria licenza unica conservata in /usr/share/licenses/$pkgname/.
  • Alcuni pacchetti non possono essere oggetto di una singola licenza. In questi casi possono essere immesse più voci nell'array licenza, per esempio license=("GPL" "custom:some commercial license"). Per la maggior parte dei pacchetti queste licenze si applicano in diversi casi, invece di applicarle allo stesso tempo. Una volta che a pacman sarà aggiuntà la possibilità di filtrare i risultati in base alle licenze (in modo da poter scegliere ad esempio: "voglio solo software rilasciato sotto licenze BSD e GPL"), software rilasciati sotto licenze duplici (o multiple) saranno trattati da pacman con logica OR piuttosto che AND, in modo che pacman prenda in considerazione nell'esempio succitato tutti i software rilasciati almeno sotto una delle due licenze GPL e BSD, tralasciando tutti gli altri.
  • La (L)GPL ha molte versioni e permutazioni di tali versioni. Per il software (L)GPL, la convenzione è:
    • (L)GPL - (L)GPLv2 od ogni versione successiva
    • (L)GPL2 - (L)GPL2 solo
    • (L)GPL3 - (L)GPL3 od ogni versione successiva

Invio di pacchetti ad AUR

Si osservino le seguenti specifiche prima di inviare qualsiasi pacchetto ad AUR:

  1. I PKGBUILD inviati NON devono assolutamente essere già presenti in nessuno dei repository binari ufficiali. L'unica eccezione a questa rigorosa regola può essere solo quella di pacchetti con caratteristiche o funzionalità extra, e/o con eventuali patch che li contraddistinguono da quelli ufficiali. In tali occasioni l'array pkgname dovrebbe essere diverso per specificare queste differenze. Esempio: Un PKGBUILD con uno schermo GNU inviato con la patch sidebar, potrebbe essere chiamato screen-sidebar ecc. Inoltre, l'array del PKGBUILD provides=('screen') dovrebbe essere utilizzato al fine di evitare conflitti con il pacchetto ufficiale.
  2. Per garantire la sicurezza dei pacchetti inviati ad AUR si prega di verificare di aver compilato correttamente il campo md5sum. L'md5sum può essere generato utilizzando il comando makepkg -g.
  3. Si prega di aggiungere una riga di commento nella parte superiore del file PKGBUILD che segue questo formato. Ricordarsi di mascherare il proprio indirizzo e-mail per evitare lo spam:
    # Maintainer: Your Name <address at domain dot com>

    Se si sta assumendo il ruolo di manutentore di un PKGBUILD esistente, aggiungere il proprio nome in cima come descritto sopra e cambiare il titolo del precedente Maintainer a Contributor:

    # Maintainer: Your Name <address at domain dot com>
    # Contributor: Previous Name <address at domain dot com>
  4. Verificare le dipendenze del pacchetto (ad esempio, eseguire ldd su eseguibili dinamici, controllare i tool richiesti dagli script, ecc). I TU raccomandano vivamente l'utilizzo dell'utilità namcap, elaborato da Jason Chu (jason@archlinux.org), per analizzare lo stato dei pacchetti. Namcap avviserà riguardo permessi errati, dipendenze mancanti, dipendenze non richieste, ed altri errori comuni. Si può installare il pacchetto namcap con pacman. Ricordare inoltre che namcap può essere usato per controllare sia file pkg.tar.gz che PKGBUILD.
  5. Le dipendenze sono tra gli errori più comuni riguardo la pacchettizzazione. Namcap può aiutare a rilevarle, ma non è sempre infallibile. Verificare le dipendenze consultando la documentazione dei sorgenti e il sito web del programma.
  6. Non utilizzare replaces in un PKGBUILD a meno che il pacchetto debba essere rinominato, per esempio quando Ethereal diventa Wireshark. Se il pacchetto è una versione alternativa di un pacchetto già esistente, usare conflicts (e provides se tale pacchetto è richiesto da altri). La differenza principale è che dopo la sincronizzazione (-Sy), pacman vuole subito sostituire il pacchetto installato, per trovare un pacchetto con il "matching" replaces da qualche parte nei suoi repository; conflicts d'altra parte viene considerato solo quando ha effettivamente luogo l'installazione del pacchetto, che di solito è il comportamento desiderato, dato che è meno invasivo.
  7. Tutti i file caricati su AUR devono essere contenuti in un file tar compresso contenente una directory con il PKGBUILD e i file di compilazione aggiuntivi (patch, install, ...).
    foo/PKGBUILD
    foo/foo.install
    foo/foo_bar.diff
    foo/foo.rc.conf

    Il nome dell'archivio dovrebbe contenere il nome del pacchetto, ad esempio foo.tar.gz.

    Si può facilmente compilare un archivio contenente tutti i file richiesti utilizzando makepkg --source. Questo rinominerà un tarball $pkgname-$pkgver-$pkgrel.src.tar.gz, che può essere poi caricato su AUR.

    Il tarball non dovrebbe contenere nè il tarball binario creato da makepkg, né la filelist.

Linee guida supplementari

Si raccomanda di leggere per prima cosa le linee guida descritte sopra: molti concetti importanti sono spiegati in questa pagina e non verranno ripetuti nelle seguenti guide specifiche, che sono intese come un complemento agli standard elencati in questa pagina.

CVS/SVN Packages

Si prega di consultare Arch CVS & SVN PKGBUILD guidelines

Eclipse Plugin Packages

Si prega di consultare Eclipse plugin package guidelines

Gnome Packages

Si prega di consultare Gnome package guidelines

Haskell Packages

Si prega di consultare Haskell package guidelines

Java Packages

Si prega di consultare Java Package Guidelines

Kernel Module Packages

Si prega di consultare Kernel Module Package Guidelines

Lisp Packages

Si prega di consultare Lisp Package Guidelines

OCaml Packages

Si prega di consultare OCaml_Package_Guidelines

Perl Packages

Si prega di consultare Perl Package Guidelines

Python Packages

Si prega di consultare Python Package Guidelines

Ruby Gem Packages

Si prega di consultare Ruby Gem Package Guidelines

Wine Packages

Si prega di consultare Arch wine PKGBUILD guidelines