Usando portage correctamente

A traveso de gentoo-es.org veño de atopar un artigo estupendo. Tódolos que estedes a usar esta distribución linux, invítivos a que o leades. De seguido tedes unha traducción ó galego.

O sistema portage de gentoo é un recurso excelente cando se usa apropiadamente; o uso incorrecto, pode desembocar nun sistema desordeado, con paquetes e ficheiros descontrolados, e un ficheiro world incorrecto. Seguindo esta guía o usuario terá un sistema limpo e ordeado.

emerxendo paquetes:
emerge foo

Non se debe usar ACCEPT_KEYWORDS="~x86" para instalar paquetes masked, porque, entre outras cousas, instalará tamén as dependencias na súa versión inestable.

O método adecuado é: Intentar instala-lo paquete, se portage nos comunica que o ebuild é inestable, toma-la solución apropiada (abaixo).
Se unha vez resolto, ó instala-lo paquete, algunha dependencia se queixa, por estar tamén masked repítese a solución apropiada (abaixo).
Si, isto pode parecer unha dor, frente ós rápidos USE="blah" emerge foo ou ACCEPT_KEYWORDS="~x86" emerge foo pero é a forma que portage ten de leva-lo control de paquetes, incluso dos inestables, correctamente.

ATENCIÓN: emerxer directamente un ebuild: emerge /path/to/foo.ebuild pode causar problemas e NON debe ser usado; en ocasións este método de instalación, rexeita engadi-lo paquete ó ficheiro world, ademáis usando este método portage non nos notificará das novas versións do paquete aínda cando estas puideran conter importantes correccións de seguridade.

MANTENDO PAQUETES:

Algunhas veces, cando executamos emerge -u world portage quere retroceder na versión dalgún paquete (por exemplo, se está masked).
A solución é engadi-lo nome completo do paquete, seguido de ~x86 no arquivo /etc/portage/package.keywords.
Por exemplo, para que portage recoñeza que queremos te-la versión inestable de gaim no noso sistema:

echo net-im/gaim ~x86 >> /etc/portage/package.keywords

Se fas isto para tódolos paquetes inestables, quedarán correctamente baixo o control de portage, entón non tratará de volver á última versión estable.

Tamén podemos determinar versións específicas, de forma que portage non actualizará nin retrocederá as versións.

echo = app-misc/foo-version ~x86 >> /etc/portage/package.keywords

A liña anterior, permite que unha versión específica sexa mantida. Tamén podemos indicar se queremos que ademáis da versión específica, as seguintes versións a pesares de estar masked, tamén poidan ser instaladas baixo o control de portage.
Facendo así posible, instalar un paquete masqued e ademáis actualizalo a medida que sallan novas versións masked

echo ~app-misc/foo-version ~x86 >> /etc/portage/package.keywords
(onde versión é a versión sen -rX, por exemplo, en foo-1.2-r4 sobraría -r4).

NOTA: É moito máis sinxelo levar un control dos paquetes, se a lista está ordeada alfabéticamente.

ATENCIÓN: Usar emerge -U world podería causar problemas co sistema e NON debe usarse. Explícase e debate este tema en gentoo-forums.

Non obstante, algunhas veces portage segue querendo retroceder na versión dun paquete, a pesares de aplica-la solución anterior. Xeralmente hai unha boa razón para isto, e é recomendable facer caso a portage. Hai algunha excepción, coas que se pode usar outro método pero SÓ se debe usar para estas excepcións. Por exemplo linux-headers:

echo sys-kernel/linux-headers -* >> /etc/portage/package.keywords

NOTA: linux-headers-2.4.x funciona perfectamente, aínda que teñas un kernel 2.6.x instalado, é só un exemplo gráfico de cómo usar esa solución.

Ás veces, algúns paquetes, tentan volver ó sistema, tras ser desinstalados, aínda cando non son precisos. Os usuarios de x.org terán detectado a xfree tentando volver ó sistema, para corrixir isto:

echo x11-base/xfree >> /etc/portage/package.mask

Existen tamén paquetes que están hard masked un exemplo é realone, está hard masked porque contén un furado de seguridade que pode compromete-la seguridade do sistema. Se por algunha razón, queremos instalar realone, ou algún outro paquete hard masked hai unha forma correcta de facelo:

echo media-video/realone >> /etc/portage/package.unmask

Se queres que un paquete non inclúa, ou inclúa algún valor USE (que non estea así indicado en /etc/make.conf) a forma adecuada de facelo, para que portage manteña o control sobre os valores USE dese paquete sempre, é algo como:

echo net-p2p/bittorrent -X >> /etc/portage/package.use

MANTENDO O FICHEIRO WORLD

En raras ocasións, os paquetes non son engadidos a world por algunha razón. Para intentar correxir isto:

regenworld

¿CÓMO FUNCIONA DEPCLEAN?

Ben, agora que aprendimos como mante-lo rexistro dos nosos programas (ficheiro world) e con elo o control sobre eles. Imos ver, para que serve e como funciona a ferramenta depclean:

Cando executamos: emerge depclean depclean toma o ficheiro world, e calcula tódalas dependencias dos elementos que están neste. Calquera cousa que non estea no ficheiro world, nin é dependencia (indirecta ou directa) de algo que está no world, é eliminado.

Exemplo de depclean
emerge gnome instalarádep1, dep2a, dep2b, dep2, dep3, logo gnome, e engadirá gnome ó arquivo world.
gtkapp depende de dep1 e dep3. emerge gtkapp instalará gtkapp e engadirao ó ficheiro world.
emerge -C gnome desinstalará gnome, e eliminarao do world, pero deixa as 5 dependencias no sistema.
emerge depclean lerá entón o world, calculará as dependencias, e dende que gnome se foi, non hai paquetes que dependan de: dep2a,,
dep2b, ou dep2, estos serán eliminados. Sen embargo dep1 e dep3 manteranse no sistema, xa que son dependencia de gtkapp, que está en world.

NOTA: Imaxino, que coma eu ata fai moi pouco, pensaredes que depclean é un suicidio, que non funciona ben, pero todo o contrario, funciona tan ben, como o teu ficheiro world estea mantido. Citando algúns post nos foros de gentoo sobre este tema:

Packages installed: 547
Packages in world: 155
Packages in system: 79
Unique package names: 547
Required packages: 563
Number to remove: 0

ACTUALIZACIÓN:

Cando lin sobre este tema, en gentoo forums atopei un par de scripts, escritos por etcatmur (gracias polo traballo ;-), Filesystem cruft script e dep script.
O primeiro, utilízase para limpa-lo sistema de ficheiros, é dicir, devólveche unha lista de ficheiros, que non pertencen a ningún paquete instalado, e controlado por portage.
O segundo, trata de minimiza-lo contido do ficheiro world, eliminando entradas, que etcatmur considera recursivas. Para telo claro, aquí hai un exemplo de saída en pantalla:

# dep -w
!!!REDUNDANT!!! app-admin/gkrellm depended on by:
x11-plugins/gkrellflynn-0.6
x11-plugins/gkrellmoon-0.6
x11-plugins/gkrellmss-2.3
app-admin/syslog-ng
!!!REDUNDANT!!! app-editors/gvim depended on by:
app-text/vim-latex-1.5_rc1
app-vim/info-1.7-r1
app-editors/nano
app-emulation/wine
x11-themes/mplayer-skins
x11-themes/nautilus-themes

145 packages in worldfile: 137 valid, 8 redundant; 70 packages in system.
563 packages installed: 12% in system, 25% in world, 63% deps.

Ben, persoalmente, penso que é moito mellor, levar ordeado o sistema, e o rexistro dende un principio, usando portage correctamente que tratar de ordear algo desordeado. O principal inconvinte, é que, como vedes, o script, decide elimina-la entrada app-admin/gkrellm por que, esta xa é dependencia, doutros paquetes que constan no ficheiro world.

¿Cal é o problema disto? que se un día decido desinstalar gkrellflynn, gkrellmoon, gkrellmss polo que sexa, e incluso decido cambiar de logger, e tamén desinstalo syslog-ng, entón non quedará nada no world, referente a gkrellm, e cando execute emerge depclean trataría de desinstalalo.

Esto non pasaría só con gkrellm, así que desbarata todo o orde que intentamos acadar con este artigo.
De todas formas, votade un ollo a este script tamén porque ten outras funcións que resultan moi últiles, como calcula-las dependencias inversas dun paquete.

ACTUALIZACIÓN

Despois dalgunhas experiencias intentando manter limpo o rexistro do sistema, dinme conta de que hai casos especiais, onde un ordenador non pode intervir, decidindo por nós, que queremos ou non. Para ver isto, escribín unha experiencia real, a modo de exemplo. Escribirei máis experiencias coma esta segundo se me vaian plantexando casos especiais nos que a intervención do usuario/administrador é inevitable. Ésta é a ligazón.

Agradecementos a NuclearFusi0n e GaMMa polas ideas orixinais, e por compartilas con toda a comunidade.

Fonte: nolbox.homelinux.org