:B~ Personalització de la instaŀlació de paquets

1~customizing-package-installation Personalització de la instaŀlació de
paquets

La personalització més bàsica d'un sistema Debian live pot ser la selecció
dels paquets que seran inclosos en la imatge. Aquest capítol explica les
diverses opcions de live-build per personalitzar la instaŀlació de paquets
durant la construcció. Les opcions més importants que influeixen en els
paquets que estan disponibles per ser instaŀlats en la imatge són les àrees
de distribució i el arxiu. Per garantir velocitats de descàrrega decents,
s'ha de triar un mirall de distribució proper. També es pot incloure
repositoris de backports, paquets experimentals o personalitzats, o incloure
paquets directament com si fossin fitxers. Es poden definir llistes de
paquets, incloent-hi els metapaquets que instaŀlaran diversos paquets
relacionats alhora, com ara paquets per a un ordinador d'escriptori o un
llenguatge en particular. Finalment, una sèrie d'opcions donen un cert
control sobre /{apt}/ o si es prefereix /{aptitude}/, quan s'instaŀlen els
paquets durant la construcció. Això pot ser útil si s'utilitza un proxy, es
vol desactivar la instaŀlació de paquets recomanats per estalviar espai, o
hi ha la necessitat de controlar quines versions dels paquets s'instaŀlen
mitjançant la tècnica pinning d'APT, per nomenar algunes possibilitats.

2~ Fonts dels paquets

3~ Distribució, àrees d'arxiu i mode 

La distribució que es tria té una gran importància en els paquets que estan
disponibles per incloure en una imatge en viu. Només cal especificar el nom
en clau, que per defecte és wheezy per a la versió wheezy de
live-build. Qualsevol distribució disponible a l'arxiu de Debian pot ser
especificada pel seu nom en clau aquí. (Veure {Termes}#terms per més
detalls.) L'opció #{--distribution}# no només influeix en l'origen dels
paquets dins l'arxiu, sinó que també instrueix a live-build per comportar-se
segons sigui necessari per a construir cada distribució suportada. Per
exemple, per construir la distribució *{unstable}*, sid, s'ha d'especificar:

code{

 $ lb config --distribution sid

}code

A l'arxiu de la distribució, les àrees són les divisions principals de
l'arxiu. A Debian, es tracta de #{main}#, #{contrib}# i #{non-free}#.  Només
#{main}# conté el programari que és part de la distribució Debian, per tant
és el valor per defecte. Es poden especificar un o més valors, per exemple:

code{

 $ lb config --archive-areas "main contrib non-free"

}code

És dona suport experimental a alguns derivats de Debian a través de l'opció
#{--mode}#. Per defecte, aquesta opció és #{debian}# però només si s'està
construint en un sistema Debian o en un sistema desconegut. Si s'especifica
amb #{lb config}# que es vol construir un dels derivats suportats alehores
es modificaran les opcions per crear aquest derivat. Si per exemple
s'utilitza #{lb config}# amb el mode #{ubuntu}#, s'utilitzarà el nom de la
distribució i les àrees dels arxius del derivat especificat en lloc dels de
Debian. El «mode» també modifica el comportament de live-build per
adaptar-lo als derivats.

*{Nota:}* Els projectes per als quals s'han afegit aquests modes són els principals responsables de donar suport als usuaris d'aquestes opcions. El projecte Debian Live, al seu torn, dona suport de desenvolupament només sobre una base de millor esforç, basada en les informacions proporcionades pels projectes derivats ja que nosaltres no desenvolupem ni donem suport a aquests derivats.

3~ Miralls de distribució

L'arxiu de Debian es replica a través d'una àmplia xarxa de miralls a tot el
món perquè la gent de cada regió pugui triar un mirall proper amb la millor
velocitat de descàrrega. Cadascuna de les opcions #{--mirror-*}# governa
quin mirall de distribució s'utilitzarà en les diverses etapes de la
construcció. Recordar de {Etapes de la construcció}#stages-of-the-build que
l'etapa *{bootstrap}* es quan el chroot s'omple inicialment per
/{debootstrap}/  amb un sistema mínim i l'etapa *{chroot}* és quan
s'utilitza el chroot per a la construcció del sistema de fitxers del sistema
en viu. D'aquesta manera, s'utilitzen els miralls corresponents per a
aquestes etapes, i més tard, durant l'etapa *{binary}* s'utilitzen els
valors #{--mirror-binary}# i #{--mirror-binary-security}# substituint
qualsevol mirall utilitzat en una etapa anterior.

3~distribution-mirrors-build-time Miralls de distribució utilitzats en temps
de construcció

Per establir els miralls de la distrubució utilitzats en temps de
construcció perquè apuntin a una rèplica local, és suficient establir
#{--mirror-bootstrap}#, #{--mirror-chroot-security}# i
#{--mirror-chroot-backports}# de la manera següent.

code{

 $ lb config --mirror-bootstrap http://localhost/debian/ \
          --mirror-chroot-security http://localhost/debian-security/ \
          --mirror-chroot-backports http://localhost/debian-backports/

}code

El mirall per al chroot, especificat per l'opció #{--mirror-chroot}#, per
defecte pren el mateix valor que #{--mirror-bootstrap}#

3~ Miralls de distribució utilitzats en temps d'execució

Les opcions #{--mirror-binary*}# governen els miralls de distribució que
acaben a la imatge binària. Aquestes poden ser utilitzades per instaŀlar
paquets addicionals mentre s'executa el sistema en viu. Els valors per
defecte fan servir #{http.debian.net}#, un servei que tria un mirall
geogràficament a prop en funció, entre altres coses, de la familia de la IP
de l'usuari i de la disponibilitat del mirall. Aquesta és una opció adequada
quan no es pot predir quin serà el millor mirall per tots els usuaris. O es
pot especificar els valors propis com es mostra en l'exemple següent. Una
imatge construïda a partir d'aquesta configuració només seria convenient per
als usuaris en una xarxa on "#{mirror}#" és abastable.

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 Repositoris addicionals

És possible afegir més repositoris, ampliant les opcions de paquets més
enllà dels disponibles en la pròpia distribució de destinació. Aquests poden
ser, per exemple, per backports, experimentals o paquets personalitzats. Per
configurar repositoris addicionals, crear els fitxers
#{config/archives/your-repository.list.chroot}#, i/o
#{config/archives/your-repository.list.binary}#. Igual que amb les opcions
#{--mirror-*}# aquest regeix els repositoris utilitzats en l'étapa
*{chroot}*  durant la construcció de la imatge, i a l'étapa *{binary}*, és a
dir, per ser utilitzades quan s'executa el sistema en viu.

Per exemple, #{config/archives/live.list.chroot}# permet instaŀlar paquets
des del repositori d'instantànies de debian-live en el moment de construcció
del sistema viu.

code{

 deb http://live.debian.net/ sid-snapshots main contrib non-free

}code

Si s'afegeix la mateixa línia a #{config/archives/live.list.binary}#, el
repositori sera afegit al directori #{/etc/apt/sources.list.d/}# del sistema
viu.

Si aquests fitxers existeixen, són utilitzats de forma automàtica.

També s'ha de posar la clau GPG utilitzada per signar el repositori en
fitxers #{config/archives/your-repository.key.{binary,chroot}}#.

En cas de necessitar un APT pinning personalitzat, es poden coŀlocar les
preferències APT en fitxers
#{config/archives/your-repository.pref.{binary,chroot}}#, que seran afegits
automàticament al sistema en viu al directori #{/etc/apt/preferences.d/}#.

*{Nota:}* Hi ha alguns repositoris de paquets preconfigurats que estan disponibles per facilitar la seva selecció a través de l'opció #{--archives}#, per exemple, per habilitar instantànies en viu, una simple ordre és suficient:

code{

 $ lb config --archives live.debian.net

}code

2~choosing-packages-to-install Selecció dels paquets a instaŀlar

Hi ha una sèrie de formes de triar els paquets que live-build instaŀlarà en
la imatge, que abasta una varietat de necessitats diferents. Es pot
simplement anomenar paquets individualment per instaŀlar en una llista de
paquets. També es pot optar per utilitzar metapaquets a les llistes, o
seleccionar-los utilitzant camps de control de fitxers de paquets. I,
finalment, es poden copiar paquets com si fossin fitxers dins del arbre
#{config/}#, que és un mètode que s'adapta perfectament a fer proves amb
paquets nous o experimentals abans de afegirlos a un repositori.

3~package-lists Llistes de paquets

Les llistes de paquets són una forma eficaç d'expressar quins paquets han de
ser instaŀlats. La sintaxi de la llista suporta seccions condicionals que fa
que sigui fàcil construir llistes i adaptar-les per al propi ús en múltiples
configuracions. Els noms dels paquets també poden ser injectats a la llista
amb ajudants de l'intèrpret d'ordres en temps de construcció. 

*{Nota:}* El comportament de live-build a l'hora d'especificar un paquet que no existeix està determinat per la elecció que es faci de l'eina APT. Veure {Elegir apt or aptitude}#choosing-apt-or-aptitude per més detalls.

3~using-metapackages Ús dels metapaquets

La forma més senzilla per omplir la llista de paquets és utilitzar una tasca
metapaquet mantinguda per una distribució. Per exemple:

code{

 $ lb config
 $ echo task-gnome-desktop > config/package-lists/desktop.list.chroot

}code

Això reemplaça l'antic mètode de llistes predefinides de #{live-build}#
2.x. A diferència de les llistes predefinides, els metapaquets no són
específics del projecte Debian Live. Per contra, són mantinguts per grups
d'especialistes que treballen dins la distribució i per tant, reflecteixen
el consens de cada grup sobre els paquets que serviran millor a les
necessitats dels usuaris. A més, abasten una gamma molt més àmplia de casos
d'ús que les llistes predefinides que substitueixen.

Tots els metapaquets tenen el prefix #{task-}#, de manera que una forma
ràpida de determinar quins estan disponibles (encara que pot contenir un
grapat d'entrades falses que coincideixin amb el nom, però que no són
metapaquets) és fer coincidir el nom del paquet amb:

code{

 $ apt-cache search --names-only ^task-

}code

A més d'aquests, es troben altres metapaquets amb diverses
finalitats. Alguns són subconjunts de paquets de tasques més àmplies, com
#{gnome-core}#, mentre que altres són parts individuals especialitzades de
un Debian Pure Blend, com els metapaquets #{education-*}#. Per obtenir una
llista de tots els metapaquets que hi ha a l'arxiu, instaŀlar el paquet
#{debtags}# i llistar tots els paquets amb l'etiqueta #{role::metapackage}#
de la següent manera:

code{

 $ debtags search role::metapackage

}code

3~ Llistes locals de paquets

Ja sigui afegint metapaquets a una llista, paquets individuals, o una
combinació d'ambdós, totes les llistes de paquets locals s'emmagatzemen a
#{config/package-lists/}#. Es pot utilitzar més d'una llista i això es
presta molt bé als dissenys modulars. Per exemple, es pot decidir dedicar
una llista a una elecció particular d'escriptori, l'altra a una coŀlecció de
paquets relacionats que puguin ser fàcilment utilitzats al damunt d'un
escriptori diferent. Això  permet experimentar amb diferents combinacions de
conjunts de paquets amb un mínim d'esforç, intercanviant llistes comunes
entre els diferents projectes d'imatges en viu.

Les llistes de paquets que es troben en aquest directori han de tenir el
sufix #{.list}# per ser processades, i a més a més un sufix d'etapa
adicional #{.chroot}# o #{.binary}# per indicar per a quina etapa és la
llista.

*{Nota:}* Si no s'especifica el sufix d'etapa, la llista s'utilitzarà per a ambdues etapes. Normalment, s'especifica #{.list.chroot}# de manera que els paquets només s'instaŀlaran al sistema de fitxers en viu i no hi haura una còpia extra del #{.deb}# en el medi.

3~ Llistes locals de paquets per l'etapa binary

Per crear una llista per a l'etapa binary, crear un fitxer amb el sufix
#{.list.binary}# a #{config/package-lists/}#. Aquests paquets no s'instaŀlen
al sistema de fitxers en viu però s'inclouen en el medi en viu al directori
#{pool/}#. Un ús típic d'aquesta llista seria amb una de les variants del
instaŀlador non-live. Com s'ha esmentat anteriorment, si es vol que aquesta
llista sigui la mateixa que la llista de l'etapa chroot, simplement
utilitzar el sufix #{.list}#.

3~generated-package-lists Generar llistes de paquets

De vegades passa que la millor manera de crear una llista és generar-la amb
un script. Qualsevol línia que comença amb un signe d'exclamació indica una
ordre que s'executarà dins del chroot quan la imatge es construeix. Per
exemple, es podria incloure la línia #{! grep-aptavail -n -sPackage
-FPriority standard | sort}# en una llista de paquets per produir una llista
ordenada de paquets disponibles amb #{Priority: standard}#.

De fet, la selecció de paquets amb l'ordre #{grep-aptavail}# (del paquet
#{dctrl-tools}#) és tan útil que #{live-build}# proporciona un script
#{Packages}# d'ajuda per motius de comoditat. Aquest script accepta dos
arguments: #{field}# i #{pattern}#. Per tant, es pot crear una llista amb
els següents continguts:

code{

 $ lb config
 $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot

}code

3~ Ús de condicionals dins de les llistes de paquets

Qualsevol de les variables de configuració de live-build emmagatzemades a
#{config/*}# (menys el prefix #{LB_}#) poden ser utilitzades en sentències
condicionals en les llistes de paquets. En general, això significa qualsevol
opció #{lb config}# en lletres majuscules i amb guions canviats a guions
baixos. Però a la pràctica, només tenen sentit les que influeixen en la
selecció de paquets, com ara #{DISTRIBUTION}#, #{ARCHITECTURES}# o
#{ARCHIVE_AREAS}#.

Per exemple, per instaŀlar #{ia32-libs}# si s'especifica #{--architectures
amd64}#:

code{

 #if ARCHITECTURES amd64
 ia32-libs
 #endif

}code

És possible fer un test d'un nombre de valors, per exemple per instaŀlar
/{memtest86+}/ si s'especifica #{--architectures i386}# o #{--architectures
amd64}#:

code{

 #if ARCHITECTURES i386 amd64
 memtest86+
 #endif

}code

També es pot provar amb variables que poden contenir més d'un valor, per
exemple, per instaŀlar /{vrms}/ si s'especifica o #{contrib}# o #{non-free}#
a través de l'opció #{--archive-areas}#:

code{

 #if ARCHIVE_AREAS contrib non-free
 vrms
 #endif

}code

No és possible el anidament dels condicionals.

3~desktop-and-language-tasks Tasques d'escriptori i llenguatge

Les tasques d'escriptori i el llenguatge són casos especials que necessiten
una mica de planificació i configuració extra. Les imatges en viu són
diferentes de les imatges de l'instaŀlador de Debian en aquest sentit. A
l'instaŀlador de Debian, si el medi es va preparar per obtenir un tipus
d'entorn d'escriptori en particular, la tasca corresponent s'instaŀlarà
automàticament. Per tant hi ha tasques internes #{gnome-desktop}#,
#{kde-desktop}#, #{lxde-desktop}# i #{xfce-desktop}#, cap de les quals
s'ofereixen al menú de #{tasksel}#. De la mateixa manera, no hi ha cap
entrada de menú per a tasques de llengües, però l'elecció del idioma de
l'usuari durant la instaŀlació influeix en la selecció de les tasques de les
llengües corresponents.

En el desenvolupament d'una imatge en viu d'escriptori, la imatge sol
arrencar directament a un escriptori de treball, les opcions d'escriptori i
de llengua han estat fetes en temps de construcció, no en temps d'execució
com en el cas del instaŀlador de Debian. Això no vol dir que una imatge en
viu no es pugui construir per donar suport a diversos equips d'escriptori o
diversos idiomes i oferir a l'usuari una opció, però això no és el
comportament de live-build per defecte.

Com que no hi ha cap ajust automàtic per les tasques de llengua que
incloguin coses com ara fonts específiques per a una llengua o paquets de
mètode d'entrada, si es vol, cal especificar-ho en la configuració. Per
exemple, una imatge d'escriptori GNOME que contingui suport per al alemany
podrie incloure les següents tasques metapaquets:

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 Tipus i versió del nucli

Depenent de l'arquitectura, s'inclouran per defecte en la imatge un o més
tipus de nuclis. Es pot triar diferents tipus a través de l'opció
#{--linux-flavours}#. Cada tipus té un sufix per l'arrel per defecte
#{linux-image}# per formar el nom de cada metapaquet que al seu torn depèn
d'un paquet del nucli exacte que s'ha d'incloure en la imatge.

Així, per defecte, una imatge per l'arquitectura #{amd64}# inclourà el
metapaquet #{linux-image-amd64}# i una imatge per l'arquitectura #{i386}#
inclourà els metapaquets #{linux-image-486}# i #{linux-image-686-pae}#. Al
moment d'escriure, aquests paquets depenen de #{linux-image-3.2.0-4-amd64}#,
#{linux-image-3.2.0-4-486}# i #{linux-image-3.2.0-4-686-pae}#,
respectivament.

Quan hi ha més d'una versió del nucli disponible en els arxius configurats,
es pot especificar el nom d'un paquet del nucli amb l'opció
#{--linux-packages}#. Per exemple, suposem que s'està construint una imatge
d'arquitectura #{amd64}# i es vol afegir l'arxiu experimental amb propòsits
de fer proves perquè es pugui instaŀlar el nucli
#{linux-image-3.7-trunk-amd64}#. Es podria configurar la imatge de la
següent manera:

code{

 $ lb config --linux-packages linux-image-3.7-trunk
 $ echo "deb http://ftp.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot

}code

3~custom-kernels Nuclis personalitzats

Es pot construir i incloure nuclis propis personalitzats, sempre que
s'integrin en el sistema de gestió de paquets de Debian. El sistema de
live-build no és compatible amb nuclis no construïts com paquets #{.deb}#.

La manera apropiada i recomanable d'implementar els propis paquets del nucli
és seguir les instruccions del #{kernel-handbook}#. Recordar que s'ha de
modificar l'ABI i els sufixos del tipus apropiadament, i a continuació,
incloure un conjunt complet dels packets que corresponen amb #{linux}# i
#{linux-latest}# al repositori.

Si s'opta per construir els paquets del nucli sense els metapaquets a joc,
cal especificar una arrel #{--linux-packages}# apropiada com s'indica a
{Tipus i versió del nucli}#kernel-flavour-and-version. Com expliquem a
{Instaŀlació de paquets modificats o de
tercers}#installing-modified-or-third-party-packages, és millor si
s'inclouen els paquets del nucli personalitzat en un repositori propi, tot i
que les alternatives discutides en aquella secció també funcionen.

Està més enllà de l'abast d'aquest document donar consells sobre com
personalitzar un nucli. No obstant això, cal, almenys, assegurar-se que la
configuració compleix els següents requisits mínims:

_* Utilitzar una ramdisk inicial.

_* Incloure el mòdul d'unió del sistema de fitxers (normalment #{aufs}#).

_* Incloure tots els mòduls del sistema d'arxius requerits per la
configuració (normalment #{squashfs}#).

2~installing-modified-or-third-party-packages Instaŀlació de paquets
modificats o de tercers

Si bé està en contra de la filosofia de Debian Live, de vegades pot ser
necessària la construcció d'un sistema en viu amb versions modificades dels
paquets que es troben al arxiu de Debian. Pot ser per modificar o donar
suport a funcions addicionals, les llengües o les marques, o fins i tot per
eliminar elements dels paquets existents que són indesitjables. De la
mateixa manera, es poden utilitzar paquets de tercers per afegir alguna
funcionalitat personalitzada i/o propietària.

Aquesta secció no cobreix l'assessorament en matèria de construcció o
manteniment de paquets modificats. Però el métode de Joachim Breitner's 'How
to fork privately' a
http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html
pot ser d'interès. La creació de paquets personalitzats es tracta a Debian
New Maintainers' Guide at http://www.debian.org/doc/maint-guide/ i en altres
llocs.

Hi ha dues formes d'instaŀlar paquets personalitzats modificats:

_* #{packages.chroot}#

_* L'ús d'un repositori APT personalitzat

Utilitzar #{packages.chroot}#  és més fàcil d'aconseguir i útil per a
personalitzacions "ràpides", però té una sèrie d'inconvenients, mentre que
l'ús d'un repositori APT personalitzat és més costós en la quantitat de
temps necessari per posar-lo en marxa.

3~ Fer servir #{packages.chroot}# per instaŀar paquets personalitzats

Per instaŀar un paquet personalitzat, només s'ha de copiar al directori
#{config/packages.chroot/}#. Els paquets que es troben dins d'aquest
directori s'instaŀlaran automàticament en el sistema en viu durant la
construcció - no cal especificar res més en cap altre lloc.

Els paquets *{han de}* ser nomenats en la forma prescrita. Una manera simple
de fer això és utilitzar #{dpkg-name}#.

Utilitzar #{packages.chroot}# per a la instaŀlació de paquets personalitzats
té els seus desavantatges:

_* No és possible utilitzar APT segur.

_* Cal posar tots els paquets apropiats al directori
#{config/packages.chroot/}#.

_* No es presta per a l'emmagatzematge de configuracions de Debian Live en
el control de revisió.

3~ Fer servir un repositori APT per instaŀlar paquets personalitzats

A diferència de #{packages.chroot}#, quan s'utilitza un repositori APT
personalitzat s'ha d'assegurar que s'especifiquen els paquets en un altre
lloc. Veure {Selecció dels paquets a instaŀlar}#choosing-packages-to-install
per més detalls.

Si bé crear un repositori APT per instaŀlar paquets personalitzats pot
semblar un esforç innecessari, la infraestructura pot ser fàcilment
reutilitzada en una data posterior per oferir actualitzacions dels paquets
modificats.

3~ Paquets personalitzats i APT

live-build utilitza APT per instaŀlar tots els paquets al sistema en viu,
per tant, heretarà els comportaments d'aquest programa. Un exemple rellevant
és que (assumint una configuració per defecte) si es dóna el cas que un
paquet està disponible en dos repositoris diferents, amb diferents números
de versió, APT triarà per instaŀlar el paquet amb la versió més alta.

A causa d'això, s'aconsella augmentar el nombre de la versió dels paquets
personalitzats als fixers #{debian/changelog}#  per assegurar-se que la
versió modificada és la que s'instaŀla en lloc d'una dels repositoris
oficials de Debian. Això també es pot aconseguir mitjançant l'alteració de
les preferències d'APT del sistema en viu - veure {APT pinning}#apt-pinning
per més informació.

2~ Configurar APT en temps de construcció

Es pot configurar APT a través d'una sèrie d'opcions que només s'apliquen en
temps de construcció. (La configuració d'APT al sistema en funcionament en
viu es pot fer de forma normal per als continguts del sistema en viu, és a
dir, mitjançant la inclusió de les configuracions adequades a través de
#{config/includes.chroot/}#.) Per obtenir una llista completa, buscar les
opcions que comencen amb #{apt}# a la pàgina del manual de #{lb_config}#.

3~choosing-apt-or-aptitude Elegir apt o aptitude

Es pot optar per utilitzar /{apt}/ o /{aptitude}/ a l'hora d'instaŀlar
paquets en temps de construcció. Quina utilitat s'usa es configura gràcies
al argument #{--apt}# de #{lb config}#. Escollir el mètode d'implementació
per al comportament preferit durant la instaŀlació de paquets, la diferència
notable és la forma en que es manegen els paquets que falten.

_* #{apt}#: Amb aquest mètode, si un paquet que s'especifica falta,
l'instaŀlació de paquets fallarà. Aquesta és la configuració per defecte.

_* #{aptitude}#: Amb aquest mètode, si s'especifica un paquet que falta,
l'instaŀlació de paquets tindrà èxit.

3~ L'ús d'un proxy amb APT

Una configuració típica d'APT és per fer front a la construcció d'una imatge
darrere d'un proxy. Es pot especificar el proxy per APT amb les opcions
#{--apt-ftp-proxy}# o #{--apt-http-proxy}# segons sigui necessari, per
exemple,

code{

 $ lb config --apt-http-proxy http://proxy/

}code

3~tweaking-apt-to-save-space Afinar APT per estalviar espai

Pot ser necessari estalviar espai en el medi destinat a la imatge, en aquest
cas una o altra o ambdós de les següentes opcions poden ser d'interès.

Si no es vol incloure els índexs d'APT en la imatge, es poden omitir amb:

code{

 $ lb config --apt-indices false

}code

Això no influirà en les entrades de #{/etc/apt/sources.list}#, sinó
simplement si #{/var/lib/apt}# conté els fitxers dels índexs o no. El
desavantatge és que APT necessita aquests índexs per tal d'operar en el
sistema en viu, així que abans d'executar per exemple #{apt-cache search}# o
#{apt-get install}#, l'usuari primer ha fer un #{apt-get update}# per crear
aquests índexs.

Si es considera que la instaŀlació de tots els paquets recomanats infla
massa la imatge, sempre que s'estigui preparat per fer front a les
conseqüències que s'analitzen a continuació, es pot desactivar aquesta opció
per defecte d'APT amb:

code{

 $ lb config --apt-recommends false

}code

La conseqüència més important de desactivar els «recommends» és que
#{live-boot}# i #{live-config}# recomanen alguns paquets que proporcionen
una funcionalitat important utilitzada per la majoria de configuracions
Live, com per exemple #{user-setup}# recomanat per #{live-config}# i que
s'utilitza per crear l'usuari en viu. En tots menys en els casos més
excepcionals es necessita tornar a afexir almenys alguns dels recommends a
les llistes de paquets o en cas contrari la imatge no funcionarà com
s'espera, si és que funciona. Mirar els paquets recomanats per cada un dels
paquets inclosos en la construcció i si no s'està segur que es poden ometre,
tornar a afegir-los a les llistes de paquets.

La conseqüència més general aquí és que si no s'instaŀlen els paquets
recomanats per un paquet determinat, és a dir, "els paquets que es troben
junts amb aquest en totes les instaŀlacions a menys que siguin inusuals"
(Debian Policy Manual, secció 7.2), alguns paquets que en realitat són
necessaris per als usuaris del sistema Live poden ser omesos. Per tant,
suggerim revisar la diferència que desactivar els paquets recomanats té en
la llista de paquets (veure el fitxer #{binary.packages}# generat per #{lb
build}#) i tornar a incloure a la llista els paquets que falten que haurien
de ser instaŀlats. Si només es vol deixar de banda un petit nombre de
paquets recomanats, es pot deixar els «recommends» activats i establir una
prioritat pin d'APT negativa en els paquets seleccionats per impedir la seva
instaŀlació, com s'explica a {APT pinning}#apt-pinning.

3~ Passar opcions per a apt o aptitude

Si no hi ha cap opció #{lb config}# per modificar el comportament d'APT de
la manera què es necessita, es pot utilitzar #{--apt-options}# o
#{--aptitude-options}# per passar opcions a l'eina APT
configurada. Consultar les pàgines dels manual #{apt}# i #{aptitude}# per
més detalls. Tenir en compte que ambdues opcions tenen valors per defecte
que s'hauran de mantenir, a més de les opcions que es proporcionen. Així,
per exemple, suposant que s'ha inclòs algun paquet de
#{snapshot.debian.org}# per fer proves i es vol especificar
#{Acquire::Check-Valid-Until=false}# perquè APT no es queixe de que el
fitxer #{Release}# ja ha caducat es podria fer com en el exemple següent,
afegint la nova opció després del valor per defecte #{--yes}#:

code{

 $ lb config --apt-options "--yes -oAcquire::Check-Valid-Until=false"

}code

Consultar les págines del manual per entendre completament aquestes opcions
i quan utilitzar-les. Això és només un exemple i no s'ha d'interpretar com
un consell per configurar la imatge. Aquesta opció no seria adequada, per
exemple, per una versió final d'una imatge en viu.

Per configuracions més complicades que impliquen opcions #{apt.conf}# pot
ser adequat crear un fitxer #{config/apt/apt.conf}#. Consultar també les
altres opcions #{apt-*}# per tenir algunes dreceres convenients per les
opcions que es necessiten amb freqüència.

3~apt-pinning APT pinning

Com a referència, llegir primer la pàgina del manual
#{apt_preferences(5)}#. Es pot configurar APT pinning durant la construcció,
o bé durant l'execució. En el primer cas, crear #{config/archives/*.pref}#,
#{config/archives/*.pref.chroot}#, i #{config/apt/preferences}#. Per al
segon cas, crear #{config/includes.chroot/etc/apt/preferences}#.

Suposem que s'està construint un sistema en viu wheezy però es necessita que
tots els paquets «live-» que acaben dins de la imatge binària s'instaŀlin
desde sid en temps de construcció. Cal afegir sid a les fonts d'APT i fer un
pin dels paquets live amb una prioritat més alta, però tots els altres
paquets amb una prioritat més baixa que la prioritat per defecte de manera
que només els paquets que es vol s'instaŀlin desde sid en el moment de la
construcció i tots els altres es prenguin de la distribució de destinació,
wheezy. Això es pot aconseguir de la manera següent:

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

Una prioritat pin negativa evitarà que un paquet s'instaŀli, com en el cas
que no es vulgui un paquet que és recomanat per un altre paquet. Suposem que
s'està construint una imatge LXDE afegint #{task-lxde-desktop}# a
#{config/package-lists/desktop.list.chroot}# però no es desitja que al
usuari se li demani que guardi les contrasenyes wifi al keyring. Aquesta
llista depèn de /{lxde-core}/, que recomana /{gksu}/,  que al seu torn
recomana /{gnome-keyring}/. Si es vol omitir el paquet recomanat
/{gnome-keyring}/, es pot fer mitjançant l'addició de les següents línies a
#{config/apt/preferences}#:

code{

 Package: gnome-keyring
 Pin: version *
 Pin-Priority: -1

}code
