diff options
Diffstat (limited to 'markup/pod/live-manual/media/text/it/user_customization-packages.ssi')
| -rw-r--r-- | markup/pod/live-manual/media/text/it/user_customization-packages.ssi | 652 |
1 files changed, 0 insertions, 652 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 deleted file mode 100644 index df3e991..0000000 --- a/markup/pod/live-manual/media/text/it/user_customization-packages.ssi +++ /dev/null @@ -1,652 +0,0 @@ -: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 |