# Alternative à emerge pour installer un paquet en + rapide ?

## zelurker

Genre eix mais pour installer, pas pour consulter la base.

Il y a peut-être moyen d'accélérer un peu emerge avec de la configuration, j'ai remarqué qu'il vérifie tous les digests des paquets qu'il a (pas seulement ceux concernés par l'installation !) quand on fait un emerge -av, bon les digests vont surement très vite à vérifier mais ça semble inutile quand même...

En tous cas emerge -av app-emulation/wine par exemple est terriblement lent à donner la confirmation pour que la compilation commence alors que toutes les dépendances sont déjà installées, d'où question, est-ce qu'il existe un équivalent d'eix pour l'installation, ou un moyen d'accélérer emerge ?

----------

## sebB

Je n'ai pas la réponse mais ca m'interesse aussi.

C'est un sujet récurrent.

Tu peux déjà trouver des bribes d'info dans ce post si tu ne l'a pas déjà lu

https://forums.gentoo.org/viewtopic-t-971348-postdays-0-postorder-asc-start-0.html

----------

## 324874

Salut zelurker.

La lecture de ton post me laisse dubitatif. Le propos ne fournit pas de données objectives. Le jugement est arbitraire car il repose sur une impression.

On se demande pourquoi tu aimerais que emerge aille plus vite ? Je considère ton interrogation irrecevable car tu ne fais pas l'examen et l'analyse 

des causes (seulement une présentation des perceptions). 

Il est possible d'y arriver par la connaissance de emerge et de Portage, la recherche et la réflexion.

Selon moi, il faut faire preuve de rigueur d'esprit, afin, notamment, de maintenir la qualité de ce forum.

P.S : oui, je me doute que j'enfreins une des règles du forum en publiant ce post !

Cdlt, feng

----------

## Magic Banana

Qu'as-tu mis dans MAKEOPTS que tu as du définir dans /etc/portage/make.conf ? Le -j de 'make' est certainement la configuration qui fait la plus grande différence puisqu'elle spécifie le nombre de commandes à exécuter en parallèle et que les processeurs d'aujourd'hui sont multi-cores. On entend dire que le nombre de cores (fois deux si hyperthreading) + 1 est  une valeur raisonnable.

https://wiki.gentoo.org/wiki/MAKEOPTS

----------

## Gnubyte

Je partage modestement la dubitativité de Feng.

L'installation, sur une Gentoo, pour autant que l'on ne génère pas ses paquets binaires sur une autre Gentoo qui les compilerait préalablement, est (logiquement) une activité déterministe. Le temps de CPU est incompressible et grossièrement reproductible pour une plateforme donnée, MAIS, on peut optimiser bien des choses autour.

1- compiler avec /var/tmp/portage et /tmp/ montés en tmpfs en RAM, avec pleins de mémoire.

2- utiliser un disque dur SSD, idéalement en M.2, idéalement en NVMe

3- utiliser un proc multicoeur/hyperthreadé à grosse fréquence en monocoeur, comme un i7 4770K, 4790K, 6700K, pour optimiser le parallélisme de la compilation comme la vitesse d'exécution des passages en monothread. 

Sinon, pour aller plus vite, il faut passer sur une Calculate Linux ou une Sabayon, mais on sort de la philosophie Gentoo...

Gnubyte

----------

## GentooUser@Clubic

Emerge EST lent, le calcul de l'arbre des dépendances lors d'une mise à jour ou la recherche d'un paquet est juste horrible.

Après y'a cette lenteur qui peut être contournée en utilisant un autre gestionnaire de paquet (Paludis ? j'ai jamais essayé) et y'a la durée de compilation qui elle peut difficilement être réduite sauf à investir dans du matériel plus puissant.

----------

## Gnubyte

On peut le prendre comme on veut, il faut bien compiler les sources, alors oui, c'est lent. Avec pleins de mémoire (16Go mini, 32Go si possible) et quelques utilisations élégantes de /dev/shm, ça optimise tout de même pas mal. Passer portage du python à PyPy gagnerait, qui sait, un peu, mais à quel prix ? Je ne parle même pas d'une implémentation compilée en langage de plus bas niveau.

Je livre mes lignes magiques de /dev/fstab

```
tmpfs /tmp tmpfs nodev,nosuid,noexec,mode=1777,size=16G 0 0

tmpfs /var/tmp/portage tmpfs nodev,nosuid,size=16G 0 0

/dev/ram1       none                            swap        sw,noauto  
```

On peut aussi monter le swap en /dev/shm

On compilait bien sur des 68000 ou des 386. Ne faisons pas la fine bouche à trouver emerge si lent.

----------

## sebB

On ne parle pas du temps de compilation ni du montage en tmpfs mais du temps que mets portage à calculer les dépendances.

Ca donne quoi chez toi à froid (sans jamais avoir lancé la commande emerge dans ta session), ou après un sync?

```
time emerge -uDNvp @world
```

----------

## Gnubyte

Voici le retour de ma commande uname:

```

# uname -a

Linux zeus 4.6.3-ck #1 SMP Tue Jul 12 13:14:30 CEST 2016 x86_64 Intel(R) Core(TM) i7-4770S CPU @ 3.10GHz GenuineIntel GNU/Linux

```

Il s'agit d'un hyperviseur, tournant dans une station linux fanless avec 3 disques SSD sur des ports SATA2 ICH (Crutial M4-500Go, M550-500Go, Samsung 850 Evo 1To)

Le noyau tourne depuis le M550.avec 32Go de Ram DDR3 dont swap en ramdisk, 16Go de tmpfs pour /tmp et /var/tmp/ortage

Test effectué en init default, depuis X, VMs éteintes le temps de lancer la commande. Governor performance actif. Température proc inférieure à 50°c

```

# time emerge -uDNvp @world

These are the packages that would be merged, in reverse order:

Calculating dependencies                ... done!

Total: 0 packages, Size of downloads: 0 KiB

real   0m20.252s

user   0m19.945s

sys   0m0.259s

```

avec le world suivant:

```

app-admin/logrotate

app-admin/rsyslog

app-arch/lbzip2

app-arch/lzop

app-arch/p7zip

app-arch/pigz

app-benchmarks/i7z

app-editors/vim

app-emulation/aqemu

app-emulation/libvirt

app-emulation/qemu

app-emulation/spice

app-emulation/spice-protocol

app-emulation/virt-manager

app-misc/colordiff

app-misc/icdiff

app-misc/mc

app-misc/screen

app-portage/eix

app-portage/etc-proposals

app-portage/gentoolkit

app-portage/portage-utils

app-text/tree

dev-util/strace

dev-vcs/git

mate-base/mate

mate-extra/caja-extensions

mate-extra/mate-sensors-applet

media-gfx/gnome-screenshot

media-plugins/evas_generic_loaders

media-sound/alsa-utils

media-video/ffmpeg

media-video/vlc

net-analyzer/nmapsi

net-analyzer/traceroute

net-analyzer/traceroute-nanog

net-firewall/arno-iptables-firewall

net-ftp/filezilla

net-im/qtox

net-irc/irssi

net-misc/bridge-utils

net-misc/dhcpcd

net-misc/ntp

net-misc/tightvnc

sys-apps/lm_sensors

sys-apps/mlocate

sys-apps/pciutils

sys-block/gparted

sys-boot/grub:2

sys-boot/os-prober

sys-fs/btrfs-progs

sys-kernel/ck-sources

sys-kernel/genkernel

sys-libs/gpm

sys-power/cpupower

sys-process/htop

sys-process/vixie-cron

virtual/ffmpeg

www-client/chromium

x11-base/xorg-x11

x11-misc/lightdm

x11-misc/lightdm-gtk-greeter

x11-misc/obconf

x11-misc/obmenu-generator

x11-misc/qsynergy

x11-misc/slim

x11-misc/synergy

x11-terms/rxvt

x11-terms/rxvt-unicode

x11-terms/terminology

```

Le temps est vraiment reproductible. En governor conservative ça prend 4s de plus. En governor performance, un lancé itératif ne permet pas de gagner plus de 2 ou 3 centièmes de secondes.

Cette commande emerge étant grossièrement monothread, c'est la vitesse disque et la fréquence de pointe du proc qui compte.

----------

## Gnubyte

Je ne suis peut-être qu'un vieux dino ingénu, mais par rapport au travail qui est fait, je trouve ne trouve pas ça lent, avec un i7 4770S bloqué à 3.1GHz

 *Quote:*   

> #time genkernel all  --kernel-config=/root/kconfig4 --save-config --all-ramdisk-modules --color --install  --no-zfs
> 
> real	5m13.032s
> 
> user	35m44.137s
> ...

 

Avec un 4790K non loin,aux fréquences de base, et avec le même kernel, ça dépasse à peine les 4 minutes, avec un disque SSD Crutial également.

Vous êtes durs à trouver ça long.

----------

## hackensolo

Hello,

j'utilise ccache...c'est pas vraiment une alternative mais un petit complément.

----------

