# emerge vs sources compilés

## Atreillou

hello à tous,

dans le cadre de l'installation de mon serveur, une petite question me trotte dans la tête:

g installé la gentoo 1.4rc1 et je vais commencer à installer au fur et à mesure les différents services sur ce pc:

je vais surement commencer par bind.

pour tout ce qui est installation du système, j'utilise portage et emerge   mais pour les services je me pose la question...

en effet, je veux pouvoir être sur qu'un soft important comme bind ne soit pas mis a jour lors d'un emerge -u world ou autre.

est il donc preferable de ne pas passer par portage pour installer mes services critiques? 

faut il les bloquer dans portage (cela suffit il) ?

une autre id ?

dernier cas: si j'install bind à la main et qu'apres j'install un soft qui dans sa liste de dépendance nécessite bind, ne va t il pas essayer de l'installer par dessus mon installation ? va t il voir qu il est deja installé ?

merci pour vos commentaires.

----------

## xr31Daisy

pour la dernière question, tu as l'option 'inject' de emerge.

Cela permet de signaler à portage qu'un package est installé, ( simplement updater la DB).

Ca sert exactement à installer des package à la main.

----------

## TGL

 *Atreillou wrote:*   

> 
> 
> est il donc preferable de ne pas passer par portage pour installer mes services critiques? 
> 
> faut il les bloquer dans portage (cela suffit il) ?
> ...

 

De manière générale, je préfère faire avec portage qd c'est possible. Ce que je fais moi, c'est qu'après avoir installé un paquet à proteger, je rajoute ">categorie/nom-x.x.x" dans mon packages.mask. Je maintiens ce masque d'un rsync à l'autre grâce à un alias du genre:

```

alias emerge-rsync="cp /usr/portage/profiles/packages.mask /root ; \

emerge rsync ;  \

vimdiff /root/packages.mask /usr/portage/profiles/packages.mask"

```

Y'aurait surement moyen de faire mieux, mais pour l'instant ça me suffit (et puis j'aime bien syst'ematiquement surveiller ce qu'il y a de nouveau dans le masque). On pourrait aussi imaginer un fichier de masque perso, que emerge-rsync concatene systématiquement au nouveau packages.mask. 

```

alias emerge-rsync = "emerge rsync ; \

cat /root/packages.mask.local >> /usrportage/profiles/packages.mask"

```

----------

## Atreillou

je ne connais pas l utilisation du fichier packages.mask   je vais donc me documenter

la fonction injecte me parait etre une bonne chose.

il ne me retse plus qu'a trouver comment dire a gentoo de ne jamais updater tel ou tel package lors d'un emerge -u world par ex.  (c peut etre la fonction du fichier packages.mask)

merci à vous 2

----------

## TGL

À propos du fichier packages.mask : c'est une liste de packages à ne pas installer. Elle est maintenues par les dévelopeurs gentoo au fur et à mesures de leurs tests, des corrections de bugs, etc. Le truc, c'est que tu peux parfaitement y ajouter ce que tu veux, par exemple ">=net-dns/bind-9.2.2" si tu ne veux conserver ton bind 9.2.1, etc. 

Le problème, c'est que le fichier est mis à jour (comprendre: écrasé) quand tu fais un "emerge rsync", d'où le besoin de le maintenir un peu si tu as des exigences particulières.

EDIT: oups... sed -e s/packages\.mask/package\.mask/ sur mes deux posts.Last edited by TGL on Mon Dec 16, 2002 6:09 pm; edited 1 time in total

----------

## Atreillou

et il n'existe pas de fichier a vocation inverse:

du style packages.agarder  :Wink:   dans lequel tu pourrais mettre la liste de tous les package a coonserver et à ne pas écraser ?

----------

## TGL

non, mais je pense que tu pourrais faire un truc du genre :

```

for p in `cat /root/package.keep` 

do

  cat \>${p} >> /usr/portage/profiles/package.mask

  cat \<${p} >> /usr/portage/profiles/package.mask

done

```

(enfin, un truc du genre hein... moi je suis nul en bash.)

EDIT: cat... n'importe naouak lui... echooooo ! (comme les troi petit piaf dans la vieille pub de notre enfance). J'avais dit que j'étais nul pour ces trucs là moi  :Smile: 

----------

## Atreillou

merci TGL pour tes scripts mais ne m y connaissnt encore que trop peu en bash, je vais devoir me rabattre sur la fonction -i d'emerge.

g encore quelques questions sur cette derniere:

elle permet donc d'injecter dans la base des pkg installés une version sepecifique d'un programme installé à la main.

mon test:

j'install bwmon dans /usr/local/bin

emerge -ep world | grep bwmon ne me donne rien

je fais 

server bin # emerge -i net-analyzer/bwmon-1.3

ensuite j'obtiens:

server bin # emerge -s bwmon

Searching...   

[ Results for search key : bwmon ]

[ Applications found : 1 ]

*  net-analyzer/bwmon

      Latest version available: 1.3

      Latest version installed: 1.3

      Size of downloaded files: 5 kB

      Homepage:    http://bwmon.sourceforge.net/

      Description: Simple ncurses bandwidth monitor

ce qui me laisse croire que c bon...

par contre un nouveau 

emerge -ep world | grep bwmon ne me donne toujours rien....

est ce normal ?

si oui, cela m'arrange dans la mesure ou un emerge -u world n'affectera pas ce paquet...   mais je trouve cela bien étrange  non ?

----------

## Atreillou

petite quesiton supplementaire:

le -i d'emerge ne fait que mettre a jour la base, ainsi si je fais un emerge unmerge bwmon, je risque pas d'enlever les binaires de mon pc .  c bien ca ?

----------

## dioxmat

emerge -u world n'emerge que les packages dans la liste "world".

donc si tu veux que bind ne soit pas concerne, retire le de la liste. world contient en fait tous les packages installes a la main (cad pas installes comme dependances), et c'est un simple fichier contenant les noms des packages.

le fichier se trouve par defaut dans /var/cache/edb/world.

----------

## TGL

dioxmat : c'est pas vraiment une solution... il suffit qu'un package de world dépende de bind pour que bind soit mis à jour en même temps que lui. Je préfère le masquage systématique des paquets ultérieurs parceque ça a précisement le sens "ne pas updater", c'est pas juste un effet de bord d'un comportement de particulier de emerge. C'est par exemple la seule façon de résister à un "emerge -u `qpkg -nc -I`" ou à toute autre mise à jour globale du système. L 'idéal serait biensûr que portage gère un "package.keep", ce qui éviterait d'avoir à repasser une couche de scripts ou d'alias pour gérer ça.

----------

## Atreillou

package.keep

yes !!!   j'en fait la demande !!!

et je pense que c'est une chose que l'on devrait nécessairement avoir à disposition pour ce genre de distribution sin l'on veux qu'elle soit installée sur des serveurs  (il y  a peut être moins d'intérêts sur une station de travail)

----------

## dioxmat

 *TGL wrote:*   

> dioxmat : c'est pas vraiment une solution... il suffit qu'un package de world dépende de bind pour que bind soit mis à jour en même temps que lui. Je préfère le masquage systématique des paquets ultérieurs parceque ça a précisement le sens "ne pas updater", c'est pas juste un effet de bord d'un comportement de particulier de emerge. C'est par exemple la seule façon de résister à un "emerge -u `qpkg -nc -I`" ou à toute autre mise à jour globale du système. L 'idéal serait biensûr que portage gère un "package.keep", ce qui éviterait d'avoir à repasser une couche de scripts ou d'alias pour gérer ça.

 

vi.

d'un autre cote un serveur tu ne dois pas faire une update tous les jours non plus... donc bon... perso je vois mal pourquoi ne pas si il y a une version plus recent stable ne pas la prendre... quitte a ne emerger un truc que quelques temps apres le rsync pour etre sur que il ny a pas de changements de derniere minute...

----------

## Atreillou

ma reponse est que lors d une maj vers une version stable du soft, je m'install ce dernier ds un rep a part, je la teste sur un port different tout en laissant l ancienne version en service   et quand j estime avoir fini mes tests je bascule

et avec un emerge -u je risque de ne pas pouvoir faire cela

----------

## dioxmat

d'un autre cote, si tu nas pas bind dans world, il est peu probable que tu aies un truc dependant de bind dedans egalement... donc ne pas le mettre dans world suffirait... mais bon un simple script lajoutant dans le package.mask a chaque emerge rsync marchera tres bien sinon...

----------

## Mat_le_ouf

En même temps, pour un serveur, tant que la version installée n'a pas de bugs cruciaux (genre remote access ou crash de la machine) et qu'elle fait correctement ce qu'il faut, ce n'est pas la peine de changer de version.

En pratique ça arrive assez rarement et au pire ça représente un petit temps de maintenance du serveur (ce qui est inévitable).

Concernant bind, je ne vois pas quel soft en aurait absolument besoin...

----------

## Atreillou

juste pour info:

bind n'était qu'un exemple.

il y aussi apache, php, mysql, proftpd, inn etc etc qui tourneront sur cette machine...

le script rajoutant les packages dans le mask a chaque emerge rsync semble donc etre la meilleure solution en attendant d'avoir un fichier .keep qui marche  (si cela est faisable)

----------

## Mat_le_ouf

Je maintiens ma réponse  :Smile: 

Pourquoi d'ailleurs voudrais tu toujours avoir la toute dernière version?

Si celle que tu as fait tout ce qu'il faut...

En plus la plupart du temps lors d'une mise à jour il n'y a pratiquement pas d'interruption du service.

----------

## Atreillou

c le but de la manip....

je ne veux pas (presque jamais la derniere version)

je cherche a avoir une version stable qui tourne...

par contre  j'aime bien avoir les dernieres version des petits utilitaires annexes que j'utilise...

et c donc pour cela que je veux etre sur de ne pas mettre a jour mes services vitaux sous peine de dependance avec un tout petit utilitaire  (le cas est surement plus que rare, mais mieux vaut prevenir que guerir....)

----------

## DuF

A mon avis c'est quand même bien d'avoir des versions d'apache, proftpd à jour, pour les maj de sécu (mais vaut mieux en général avec quelques jours de décalages, pour être sûr que la dernière maj n'apporte pas d'autres problèmes), mais c vrai que bind est peut être un exemple à part. Pour ma part si vraiment c'est nécessaire j'utiliserai un script un peu comme l'a proposé TGL.

NB : Ce post n'apporte rien de concrêt, seulement mon point de vue  :Smile: 

----------

## Atreillou

tant qu il n y aura pas de fichier su style package.keep  je pense que j'utiliserais ce script....

----------

