track document samples used

1 files changed, 652 insertions, 0 deletions

diff --git a/markup/pod/live-manual/media/text/it/user_customization-packages.ssi b/markup/pod/live-manual/media/text/it/user_customization-packages.ssi
new file mode 100644
index 0000000..df3e991
--- /dev/null
+++ b/markup/pod/live-manual/media/text/it/user_customization-packages.ssi
@@ -0,0 +1,652 @@
+:B~ Personalizzare l'installazione dei pacchetti
+
+1~customizing-package-installation Personalizzare l'installazione dei
+pacchetti
+
+Perhaps the most basic customization of a live system is the selection of
+packages to be included in the image. This chapter guides you through the
+various build-time options to customize live-build's installation of
+packages. The broadest choices influencing which packages are available to
+install in the image are the distribution and archive areas. To ensure
+decent download speeds, you should choose a nearby distribution mirror. You
+can also add your own repositories for backports, experimental or custom
+packages, or include packages directly as files. You can define lists of
+packages, including metapackages which will install many related packages at
+once, such as packages for a particular desktop or language. Finally, a
+number of options give some control over /{apt}/, or if you prefer,
+/{aptitude}/, at build time when packages are installed. You may find these
+handy if you use a proxy, want to disable installation of recommended
+packages to save space, or need to control which versions of packages are
+installed via APT pinning, to name a few possibilities.
+
+2~ Sorgenti dei pacchetti
+
+3~ Distribuzione, le aree di archivio e le modalità
+
+The distribution you choose has the broadest impact on which packages are
+available to include in your live image. Specify the codename, which
+defaults to ${testing} for the ${testing} version of live-build. Any current
+distribution carried in the archive may be specified by its codename
+here. (See {Terms}#terms for more details.) The #{--distribution}# option
+not only influences the source of packages within the archive, but also
+instructs live-build to behave as needed to build each supported
+distribution. For example, to build against the *{unstable}* release, sid,
+specify:
+
+code{
+
+ $ lb config --distribution sid
+
+}code
+
+All'interno dell'archivio dei pacchetti, le aree sono le principali
+divisioni dello stesso. In Debian queste sono #{main}#, #{contrib}# e
+#{non-free}#; soltanto #{main}# contiene il software che è parte di Debian,
+perciò questa è la predefinita. Possono essere specificati uno o più valori:
+
+code{
+
+ $ lb config --archive-areas "main contrib non-free"
+
+}code
+
+Attraverso l'opzione #{--mode}# è disponibile un supporto sperimentale per
+alcune derivate di Debian; per impostazione predefinita, questa opzione è
+impostata su #{debian}# solo se si sta costruendo su un sistema Debian o
+sconosciuto. Invocando #{lb config}# su una delle derivate supportate, verrà
+creata un'immagine di quella derivata in modo predefinito. Se #{lb config}#
+viene ad esempio eseguito in modalità #{ubuntu}#, saranno gestiti i nomi
+della distribuzione e le aree di archivio per la derivata specificata e non
+quelli di Debian. La modalità cambia anche il comportamento di live-build
+per adattarlo alle derivate.
+
+*{Note:}* The projects for whom these modes were added are primarily responsible for supporting users of these options. The ${project}, in turn, provides development support on a best-effort basis only, based on feedback from the derivative projects as we do not develop or support these derivatives ourselves.
+
+3~ Mirror delle distribuzioni
+
+L'archivio Debian è replicato attraverso una vasta rete di mirror in tutto
+il mondo cosicché chiunque in ogni nazione può selezionare il mirror più
+vicino per una migliore velocità di scaricamento. Ciascuna delle opzioni
+#{--mirror-*}# determina quale mirror della distribuzione è usato nei vari
+stadi della compilazione. Ricordando dalle {Fasi della
+creazione}#stages-of-the-build che la fase di *{avvio}* è quando il chroot è
+inizialmente popolato da /{debootstrap}/ con un sistema minimale e quella di
+*{chroot}* è quando viene creato il chroot usato per costruire il file
+system del sistema live. Perciò per queste fasi vengono usati i
+corrispondenti cambi di mirror, e in seguito, nella fase *{binaria}* vengono
+usati i valori di #{--mirror-binary}# e #{--mirror-binary-security}#
+sostituendo qualsiasi altro mirror usato nelle fasi iniziali.
+
+3~distribution-mirrors-build-time Mirror delle distribuzioni usati in fase
+di compilazione
+
+To set the distribution mirrors used at build time to point at a local
+mirror, it is sufficient to set #{--mirror-bootstrap}# and
+#{--mirror-chroot-security}# as follows.
+
+code{
+
+ $ lb config --mirror-bootstrap http://localhost/debian/ \
+          --mirror-chroot-security http://localhost/debian-security/
+
+}code
+
+Il mirror chroot, specificato da #{--mirror-chroot}#, è impostato al valore
+di #{--mirror-bootstrap}# in modo predefinito.
+
+3~ Mirror delle distribuzioni usate durante l'esecuzione
+
+The #{--mirror-binary*}# options govern the distribution mirrors placed in
+the binary image. These may be used to install additional packages while
+running the live system. The defaults employ #{httpredir.debian.org}#, a
+service that chooses a geographically close mirror based, among other
+things, on the user's IP family and the availability of the mirrors. This is
+a suitable choice when you cannot predict which mirror will be best for all
+of your users. Or you may specify your own values as shown in the example
+below. An image built from this configuration would only be suitable for
+users on a network where "#{mirror}#" is reachable.
+
+code{
+
+ $ lb config --mirror-binary http://mirror/debian/ \
+          --mirror-binary-security http://mirror/debian-security/ \
+          --mirror-binary-backports http://mirror/debian-backports/
+
+}code
+
+3~additional-repositories Repository addizionali
+
+Si possono aggiungere altri repository, ampliando così la scelta dei
+pacchetti al di là di quelli disponibili nella distribuzione di
+destinazione. Questi possono essere, per esempio, pacchetti di backport,
+sperimentali o personalizzati. Per configurare repository aggiuntivi, creare
+i file #{config/archives/vostro-repository.list.chroot}#, o
+#{config/archives/vostro-repository.list.binary}#. Come per le opzioni
+#{--mirror-*}#, queste controlleranno i repository usati nella fase
+*{chroot}* quando si compila l'immagine, e nella fase *{binary}*, ad esempio
+per usarli quando il sistema live è avviato.
+
+Per esempio, #{config/archives/live.list.chroot}# permette di installare
+pacchetti dal repository snapshot debian-live al momento della creazione del
+sistema live.
+
+code{
+
+ deb http://live-systems.org/ sid-snapshots main contrib non-free
+
+}code
+
+Se si aggiunge la stessa riga in #{config/archives/live.list.binary}#, il
+repository verrà aggiunto alla directory #{/etc/apt/sources.list.d/}# del
+sistema live.
+
+Se questi file esistono saranno prelevati automaticamente.
+
+Bisogna inoltre inserire la chiave GPG usata per firmare il repository nei
+file #{config/archives/vostro-repository.key.{binary,chroot}}#.
+
+Se si necessita di personalizzare il pinning di APT, le sezioni di APT
+preferences possono essere inserite nei file
+#{config/archives/mio-repository.pref.{binary,chroot}}# e verranno
+automaticamente aggiunte nella directory #{/etc/apt/preferences.d/}# del
+sistema live.
+
+2~choosing-packages-to-install Scegliere i pacchetti da installare
+
+Ci sono diversi modi per scegliere quali pacchetti live-build installerà
+nell'immagine, coprendo una gamma di esigenze diverse. Si possono richiamare
+i singoli pacchetti da un elenco, usare i metapacchetti o selezionarli
+tramite il file control. E infine inserire i file dei pacchetti nell'albero
+#{config/}#, che ben si adatta a provare pacchetti nuovi o sperimentali
+prima che siano disponibili in un repository.
+
+3~package-lists Elenchi di pacchetti
+
+Gli elenchi di pacchetti sono un potente mezzo per esprimere quali pacchetti
+devono essere installati. La sintassi gestisce sezioni condizionali rendendo
+semplice la creazione di elenchi e adattarli per l'uso in molteplici
+configurazioni. I nomi dei pacchetti possono inoltre essere inseriti
+nell'elenco utilizzando script shell in fase di compilazione.
+
+*{Nota:}* quando si specifica un pacchetto che non esiste, il comportamento di live-build è determinato dalla scelta delle utilità di APT. Per ulteriori dettagli si veda {Scegliere apt o aptitude}#choosing-apt-or-aptitude.
+
+3~using-metapackages Usare metapacchetti
+
+Il metodo più semplice per popolare una lista di pacchetti è utilizzare un
+metapacchetto task manutenuto dalla distribuzione. Ad esempio:
+
+code{
+
+ $ lb config
+ $ echo task-gnome-desktop > config/package-lists/desktop.list.chroot
+
+}code
+
+This supercedes the older predefined list method supported in #{live-build}#
+2.x. Unlike predefined lists, task metapackages are not specific to the Live
+System project. Instead, they are maintained by specialist working groups
+within the distribution and therefore reflect the consensus of each group
+about which packages best serve the needs of the intended users. They also
+cover a much broader range of use cases than the predefined lists they
+replace.
+
+Tutti i metapacchetti task iniziano per #{task-}#, un modo per determinare
+quali siano disponibili (sebbene possa contenere alcuni falsi positivi che
+corrispondono al nome ma non sono metapacchetti) è di controllare il nome
+del pacchetto con:
+
+code{
+
+ $ apt-cache search --names-only ^task-
+
+}code
+
+In aggiunta a questi si trovano altri metapacchetti per vari scopi. Alcuni
+sono dei sottoinsiemi dei pacchetti task generici, come #{gnome-core}#,
+mentre altri sono parti individuali di un Debian Pure Blend, come il
+metapacchetto #{education-*}#. Per elencarli tutti installare il pacchetto
+#{debtags}# e usare il tag #{role::metapackage}# come segue:
+
+code{
+
+ $ debtags search role::metapackage
+
+}code
+
+3~ Elenchi locali dei pacchetti
+
+Se si richiede l'elenco di metapacchetti, pacchetti individuali o una
+combinazione di entrambi tutte le liste dei pacchetti locali vengono salvate
+in #{config/package-lists/}#. Giacché è possibile usare più di una lista,
+ciò si presta bene a progetti modulari. Si può ad esempio decidere di
+dedicare un elenco ad un particolare desktop, un altro ad un insieme di
+pacchetti correlati utilizzabili con desktop differenti. Questo permette di
+sperimentare diverse combinazioni di insiemi di pacchetti con il minimo
+sforzo condividendo gli elenchi tra progetti live differenti.
+
+Per essere processati, gli elenchi dei pacchetti che si trovano in questa
+directory devono avere un suffisso #{.list}# e un suffisso #{.chroot}# o
+#{.binary}# aggiuntivo per indicare per quale fase sia l'elenco.
+
+*{Nota:}* se non si specifica il suffisso l'elenco sarà usato per entrambe le fasi. Normalmente è preferibile specificare #{.list.chroot}# in modo che i pacchetti vengono installati solo nel filesystem live evitando di avere una copia extra del #{.deb}# sul dispositivo.
+
+3~ Elenchi locali di pacchetti binari
+
+Per creare un elenco di binari inserire un file con suffisso
+#{.list.binary}# in #{config/package-lists/}#; questi pacchetti non sono
+installati nel filesystem ma inclusi sul dispositivo live sotto
+#{pool/}#. Solitamente questo elenco si usa con una delle varianti non-live
+dell'installatore; come detto sopra, se si vuole che questo sia identico
+all'elenco della fase chroot, usare semplicemente il suffisso #{.list}#.
+
+3~generated-package-lists Elenchi di pacchetti generati
+
+Talvolta succede che il modo migliore per ottenere un elenco è di generarlo
+con uno script. Ogni riga che inizia con un punto esclamativo indica un
+comando da eseguire nel chroot quando viene creata l'immagine. Ad esempio si
+potrebbe includere la riga #{! grep-aptavail -n -sPackage -FPriority
+standard | sort}# in una lista di pacchetti per produrne una contenente i
+pacchetti con #{Priority: standard}# disponibili.
+
+Infatti selezionare i pacchetti con il comando #{grep-aptavail}# (presente
+nel pacchetto #{dctrl-tools}#) è talmente utile che #{live-build}# fornisce
+uno script #{Packages}# per comodità; accetta due argomenti: #{field}# e
+#{pattern}#. Per cui si può creare un elenco con il seguente contenuto:
+
+code{
+
+ $ lb config
+ $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot
+
+}code
+
+3~ Usare condizioni all'interno degli elenchi di pacchetti
+
+Ognuna delle variabili di configurazione di live-build situate in
+#{config/*}# (senza il prefisso #{LB_}#) possono essere utilizzate per
+istruzioni condizionali nell'elenco dei pacchetti. In genere questo
+significa qualsiasi opzione di #{lb config}# in maiuscolo e con trattini
+cambiati in trattini bassi; ma in pratica è la sola ad influenzare la
+selezione dei pacchetti che abbia senso, come #{DISTRIBUTION}#,
+#{ARCHITECTURES}# o #{ARCHIVE_AREAS}#.
+
+Per esempio, per installare #{ia32-libs}# se è specificata #{--architectures
+amd64}#:
+
+code{
+
+ #if ARCHITECTURES amd64
+ ia32-libs
+ #endif
+
+}code
+
+Si può provare per ognuna di una serie di valori, ad esempio per installare
+/{memtest86+}/ specificando sia #{--architectures i386}# sia
+#{--architectures amd64}#:
+
+code{
+
+ #if ARCHITECTURES i386 amd64
+ memtest86+
+ #endif
+
+}code
+
+È possibile provare altre variabili che contengano più di un valore, ad
+esempio per installare /{vrms}/ specificando sia da #{contrib}# sia da
+#{non-free}# tramite #{--archive-areas}#:
+
+code{
+
+ #if ARCHIVE_AREAS contrib non-free
+ vrms
+ #endif
+
+}code
+
+Le condizioni nidificate non sono supportate.
+
+% FIXME:
+
+3~ Removing packages at install time
+
+You can list packages in files with #{.list.chroot_live}# and
+#{.list.chroot_install}# suffixes inside the #{config/package-lists}#
+directory. If both a live and an install list exist, the packages in the
+#{.list.chroot_live}# list are removed with a hook after the installation
+(if the user uses the installer). The packages in the
+#{.list.chroot_install}# list are present both in the live system and in the
+installed system. This is a special tweak for the installer and may be
+useful if you have #{--debian-installer live}# set in your config, and wish
+to remove live system-specific packages at install time.
+
+3~desktop-and-language-tasks Task per desktop e lingua
+
+I task per i desktop e la lingua sono un caso particolare che necessita di
+ulteriori pianificazioni e configurazioni e in questo senso le immagini live
+sono diverse da quelle dell'Installatore Debian. Nell'Installatore Debian,
+se il supporto è stato preparato per un particolare ambiente desktop, il
+corrispondente task verrà automaticamente installato. Perciò ci sono task
+#{gnome-desktop}#, #{kde-desktop}#, #{lxde-desktop}# e #{xfce-desktop}#
+interni, nessuno dei quali è offerto nel menu di #{tasksel}#. Allo stesso
+modo, non c'è nessuna voce nel menu per i task delle lingue, ma la scelta
+della lingua dell'utente durante l'installazione influenza la selezione dei
+corrispondenti task della lingua.
+
+Sviluppando un'immagine live per desktop, questa si avvia direttamente su
+un'area di lavoro, le scelte del desktop e della lingua predefinita sono
+state fatte al momento della compilazione e non al volo come nel caso
+dell'installatore Debian. Questo non per dire che un'immagine live non possa
+essere creata con un supporto per desktop o lingue multipli per offrire
+all'utente una scelta, ma che non è il comportamento predefinito nella
+creazione di una live.
+
+Poiché automaticamente non viene fatta alcuna preparazione sui task della
+lingua, i quali includono cose come caratteri specifici per la lingua e
+pacchetti per i metodi di input, se li si vogliono, vanno specificati nella
+configurazione. Per esempio, un'immagine del desktop GNOME contenente il
+supporto per il tedesco può includere questi metapacchetti task:
+
+code{
+
+ $ lb config
+ $ echo "task-gnome-desktop task-laptop" >> config/package-lists/my.list.chroot
+ $ echo "task-german task-german-desktop task-german-gnome-desktop" >> config/package-lists/my.list.chroot
+
+}code
+
+3~kernel-flavour-and-version Tipi e versioni del kernel
+
+A seconda dell'architettura, nell'immagine verranno inclusi uno o più tipi
+di kernel in modo predefinito. È possibile scegliere tipi differenti tramite
+l'opzione #{--linux-flavours}#, ognuno ha come suffisso #{linux-image}# che
+costituisce il nome del metapaccchetto che a sua volta dipende dall'esatto
+pacchetto del kernel da inserire nell'immagine.
+
+Thus by default, an #{amd64}# architecture image will include the
+#{linux-image-amd64}# flavour metapackage, and an #{i386}# architecture
+image will include the #{linux-image-586}# metapackage.
+
+When more than one kernel package version is available in your configured
+archives, you can specify a different kernel package name stub with the
+#{--linux-packages}# option. For example, supposing you are building an
+#{amd64}# architecture image and add the experimental archive for testing
+purposes so you can install the #{linux-image-3.18.0-trunk-amd64}#
+kernel. You would configure that image as follows:
+
+code{
+
+ $ lb config --linux-packages linux-image-3.18.0-trunk
+ $ echo "deb http://ftp.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot
+
+}code
+
+3~custom-kernels Kernel personalizzati
+
+Si può compilare e includere i propri kernel personalizzati a patto che
+siano integrati nel sistema di gestione dei pacchetti di Debian. Il sistema
+live-build non supporta i kernel né crea pacchetti #{.deb}#.
+
+La maniera corretta e raccommandata per collocare i propri pacchetti è di
+seguire le istruzioni nel #{kernel-handbook}#. Ricordarsi di modificare i
+suffissi per ABI e tipologia in modo appropriato quindi includere una
+compilazione completa del pacchetto #{linux}# e del corrispondente
+#{linux-latest}# nel reposistory.
+
+Se si opta per creare i pacchetti del kernel senza i metapacchetti
+corrispondenti, bisogna specificare un suffisso #{--linux-packages}#
+appropriato come discusso in {Tipi e versioni del
+kernel}#kernel-flavour-and-version. Come spiegato in {Installare pacchetti
+modificati o di terze parti}#installing-modified-or-third-party-packages, è
+meglio includere i propri pacchetti del kernel nel proprio repository,
+sebbene funzionino anche le alternative discusse in tale sezione.
+
+Fornire suggerimenti sul come personalizzare il proprio kernel va oltre lo
+scopo di questa documentazione, tuttavia è necessario assicurarsi che la
+configurazione soddisfi almeno i seguenti requisiti minimi:
+
+_* Utilizzare un ramdisk iniziale;
+
+_* includere il modulo del filesystem union (solitamente #{aufs}#);
+
+_* includere qualsiasi altro modulo del filesystem necessario alla
+configurazione (solitamente #{squashfs}#).
+
+2~installing-modified-or-third-party-packages Installare pacchetti
+modificati o di terze parti
+
+While it is against the philosophy of a live system, it may sometimes be
+necessary to build a live system with modified versions of packages that are
+in the Debian repository. This may be to modify or support additional
+features, languages and branding, or even to remove elements of existing
+packages that are undesirable. Similarly, "third-party" packages may be used
+to add bespoke and/or proprietary functionality.
+
+Questa sezione non tratta la compilazione e il mantenimento di pacchetti
+modificati. Può comunque essere interessante leggere "How to fork privately"
+di Joachim Breitner:
+http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html
+La creazione di pacchetti su misura è esposta nella "Guida per il nuovo
+Maintainer" all'indirizzo https://www.debian.org/doc/maint-guide/ e altrove.
+
+Ci sono due modi per installare pacchetti personalizzati:
+
+_* #{packages.chroot}#
+
+_* utilizzare repository APT personalizzati
+
+Usando #{packages.chroot}# è più semplice da ottenere e utile per una
+personalizzazione "una tantum" ma ha una serie di svantaggi, mentre un
+repository APT personalizzato è più laborioso da configurare.
+
+3~ Utilizzare #{packages.chroot}# per installare pacchetti personalizzati
+
+Per installare un pacchetto personalizzato copiarlo nella directory
+#{config/packages.chroot/}#; i pacchetti al suo interno verranno installati
+automaticamente durante la creazione del sistema live, non è necessario
+specificarli altrove.
+
+I pacchetti *{devono}* essere nominati nel modo prescritto, un metodo
+semplice per farlo è usare #{dpkg-name}#.
+
+L'utilizzo di #{packages.chroot}# per l'installazione di pacchetti
+personalizzati presenta degli svantaggi:
+
+_* non è possibile usare secure APT,
+
+_* è necessario installare i pacchetti adeguati nella directory
+#{config/packages.chroot/}#,
+
+_* It does not lend itself to storing live system configurations in revision
+control.
+
+3~ Utilizzare un repository APT per installare pacchetti personalizzati
+
+A differenza di #{packages.chroot}#, quando si usa un repository APT
+personalizzato è necessario assicurarsi di specificare altrove i
+pacchetti. Per i dettagli si veda {Scegliere i pacchetti da
+installare}#choosing-packages-to-install.
+
+Sebbene creare un repository APT possa sembrare uno sforzo inutile,
+l'infrastruttura può facilmente essere riutilizzata in un secondo momento
+per offrire aggiornamenti dei pacchetti modificati.
+
+3~ Pacchetti personalizzati e APT
+
+live-build utilizza APT per installare tutti i pacchetti nel sistema live in
+modo da ereditare i comportamenti di questo programma. Un esempio rilevante
+è che (considerando una configurazione predefinita) dato un pacchetto
+disponibile in due repository differenti con numeri di versione diversi, APT
+sceglie di installare quello con il numero di versione più alto.
+
+A causa di questo si può voler incrementare il numero della versione nei
+file #{debian/changelog}# dei pacchetti personalizzati per accertare che la
+propria versione avrà la precedenza sui repository Debian ufficiali. È anche
+ottenibile modificando le preferenze del APT pinning del sistema live, si
+veda {APT pinning}#apt-pinning per maggiori informazioni.
+
+2~ Configurare APT in fase di compilazione
+
+APT è configurabile tramite una serie di opzioni applicate solo in fase di
+costruzione (la configurazione di APT utilizzata nel sistema live in
+esecuzione può essere configurata nel solito modo, ovvero includendo le
+impostazioni appropriate attraverso #{config/includes.chroot/}#). Per un
+elenco completo, cercare nel manuale di #{lb_config}# le opzioni che
+iniziano con #{apt}#.
+
+3~choosing-apt-or-aptitude Scegliere apt o aptitude
+
+Per installare pacchetti in fase di compilazione si può optare sia per
+/{apt}/ sia per /{aptitude}/, l'argomento #{--apt}# di #{lb config}#
+determina quale usare. Sceglie il metodo implementando il comportamento
+preferito per l'installazione dei pacchetti, la notevole differenza è come
+vengono gestiti quelli mancanti.
+
+_* #{apt}#: se viene specificato un pacchetto mancante, l'installazione avrà
+esito negativo; questo è l'impostazine predefinita.
+
+_* #{aptitude}#: se viene specificato un pacchetto mancante, l'installazione
+avrà successo.
+
+3~ Utilizzare un proxy con APT
+
+Una configurazione di APT spesso richiesta è di amministrare la creazione di
+un'immagine dietro un proxy, lo si può specificare con le opzioni
+#{--apt-ftp-proxy}# o #{--apt-http-proxy}# secondo necessità:
+
+code{
+
+ $ lb config --apt-http-proxy http://proxy/
+
+}code
+
+3~tweaking-apt-to-save-space Modificare APT per risparmiare spazio
+
+Si può aver bisogno di risparmiare dello spazio sul supporto dell'immagine,
+in tal caso una o entrambe delle seguenti opzioni possono essere
+d'interesse.
+
+È possibile non includere gli indici di APT con:
+
+code{
+
+ $ lb config --apt-indices false
+
+}code
+
+Questo non influenzerà le voci in #{/etc/apt/sources.list}#, determina solo
+se /#{var/lib/apt}# contiene o meno i file degli indici. Il compromesso è
+che APT necessita di quegli indici per operar enel sistema live, perciò
+prima di eseguire #{apt-cache search}# o #{apt-get install}#, per esempio,
+l'utente deve usare prima #{apt-get update}# per crearli.
+
+In caso si trovi che l'installazione dei pacchetti raccomandati appesantisca
+troppo l'immagine, a patto si è preparati ad affrontare le conseguenze
+discusse prima, si può disabilitare l'opzione predefinita di APT con:
+
+code{
+
+ $ lb config --apt-recommends false
+
+}code
+
+La conseguenza più importante di disattivare i raccomandati è che
+#{live-boot}# e #{live-config}# raccomandano a loro volta alcuni pacchetti
+che forniscono funzionalità importanti utilizzate da molte configurazioni,
+come #{user-setup}# che #{live-config}# raccomanda ed è usato per creare
+l'utente live. Salvo eccezioni ci sarà bisogno di riaggiungere all'elenco
+almeno alcuni di questi o l'immagine non funzionerà come ci si
+aspetta. Controllare i raccomandati per ognuno dei pacchetti #{live-*}#
+inclusi nella compilazione, se non si è certi di poterli omettere
+aggiungerli nuovamente agli elenchi.
+
+La conseguenza generica è che se non si installano i raccomandati per un
+certo pacchetto, ovvero "pacchetti che si trovano assieme a questo eccetto
+in installazioni non usuali" (Debian Policy Manual, paragrafo 7.2), saranno
+omessi alcuni di quelli realmente necessari. Si suggerisce pertanto di
+verificare la differenza ottenuta nel proprio elenco di pacchetti
+disabilitando i raccomandati (vedere il file #{binary.packages}# generato da
+#{lb build}#) e includere nuovamente in esso quelli omessi che si desiderano
+installare. In alternativa, se si desidera tenere un modesto numero di
+raccomandati, li si lasci abilitati e si assegni ad APT un pin di priorità
+negativo sui pacchetti selezionati affinché non vengano installati, come
+spiegato in {APT pinning}#apt-pinning.
+
+3~ Passare opzioni ad apt o aptitude
+
+Se non esiste un'opzione di #{lb config}# per modificare il comportamento di
+APT come si desidera, utilizzare #{--apt-options}# o #{--aptitude-options}#
+per passare qualsiasi argomento tramite lo strumento APT scelto. Per i
+dettagli consultare le pagine di manuale di #{apt}# e #{aptitude}#. Notare
+che entrambe le opzioni hanno valori predefiniti che servirà mantenere in
+aggiunta a qualsiasi altra fornita. Per cui supponendo di aver incluso
+qualcosa da #{snapshot.debian.org}# per fare dei test e volendo specificare
+#{Acquire::Check-Valid-Until=false}# per soddisfare APT con il vecchio file
+#{Release}#, si procederà come nell'esempio riportato di seguito, appendendo
+la nuova opzione al valore predefinito #{--yes}#:
+
+code{
+
+ $ lb config --apt-options "--yes -oAcquire::Check-Valid-Until=false"
+
+}code
+
+Per apprendere a pieno queste opzioni e sapere quando usarle consultare i
+manuali. Questo è solo un esempio e non va interpretato come il modo per
+configurare la propria immagine, non sarebbe appropriato per il rilascio
+finale.
+
+Per configurazioni di APT più complesse che comportano l'uso di opzioni in
+#{apt.conf}# si può voler creare invece il file
+#{config/apt/apt.conf}#. Vedere anche le altre opzioni #{apt-*}# per alcune
+comode scorciatoie di operazioni di uso frequente.
+
+3~apt-pinning APT pinning
+
+Si prega di leggere prima il manuale di #{apt_preferences(5)}#. Il pinning
+può essere configurato sia in fase di costruzione sia di esecuzione; per la
+prima creare #{config/archives/*.pref}#, #{config/archives/*.pref.chroot}#,
+e #{config/apt/preferences}# mentre per l'ultima creare
+#{config/includes.chroot/etc/apt/preferences}#.
+
+Let's say you are building a ${testing} live system but need all the live
+packages that end up in the binary image to be installed from sid at build
+time. You need to add sid to your APT sources and pin the live packages from
+it higher, but all other packages from it lower, than the default
+priority. Thus, only the packages you want are installed from sid at build
+time and all others are taken from the target system distribution,
+${testing}. The following will accomplish this:
+
+code{
+
+ $ echo "deb http://mirror/debian/ sid main" > config/archives/sid.list.chroot
+ $ cat >> config/archives/sid.pref.chroot << EOF
+ Package: live-*
+ Pin: release n=sid
+ Pin-Priority: 600
+
+ Package: *
+ Pin: release n=sid
+ Pin-Priority: 1
+ EOF
+
+}code
+
+Un valore negativo della priorità evita che un pacchetto venga installato,
+come nel caso in cui non se ne voglia uno raccomandato da un
+altro. Supponiamo di costruire un'immagine di LXDE utilizzando l'opzione
+#{task-lxde-desktop}# in #{config/package-lists/desktop.list.chroot} ma non
+si desidera che all'utente venga richiesto di salvare la password del wifi
+nel portachiavi. Questo metapacchetto dipende da /{lxde-core}/ che
+raccomanda /{gksu}/ e che a sua volta raccomanda /{gnome-keyring}/, in
+questo caso si vorrà omettere il pacchetto /{gnome-keyring}/ aggiungendo a
+#{config/apt/preferences}# la seguente istruzione:
+
+code{
+
+ Package: gnome-keyring
+ Pin: version *
+ Pin-Priority: -1
+
+}code