Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Linux Autres OS Linux Gentoo [gentoo-user-fr] Utiliser portage/emerge avec des paquets binaires...

[gentoo-user-fr] Utiliser portage/emerge avec des paquets binaires...

14 réponses
Avatar
Ivan Havlicek
Bonjour,

Si vous en avez assez d'attendre les résultats de compilation,
vous pouvez peut-être essayer d'utiliser nos paquets binaires.
Une seule personne compile, met à jour le serveur de référence et
évite ainsi à tous les autres cette tâche fastidieuse.

Cela fait un mois que nous utilisons ce système qui permet
de récupérer des paquets déjà compilés, en particulier pour
mettre à jour nos serveurs d'hébergement.
La seule condition est que le type de votre processeur soit
déjà référencé sur notre serveur (et qu'un volontaire se soit déjà
tapé tout le boulot ;-)

=> http://rsync4.fr.gentoo.org/grp/

Vous pouvez alors ajouter les options suivantes à votre emerge :
# emerge --getbinpkgonly --usepkgonly
pour ne télécharger que les paquets déjà compilés.

Vous devez d'abord simplement ajouter à votre fichier make.conf :

# (PROC_TYPE actuellement disponibles : "c7 pentium3 pentium4 pentium4m
athlon64" )
PROC_TYPE="pentium3"
PORTAGE_BINHOST="http://gentoo.modulix.net/gentoo/grp/${CHOST}/${PROC_TYPE}"

Pour voir les options utilisées par la machine qui a compilé ces paquets,
vous pouvez voir les make.conf sur http://rsync4.fr.gentoo.org/localfiles/
(il y a aussi la configuration des noyaux)

Si vous possédez un autre type de processeur et que vous souhaitez
contribuer,
écrivez un mail à webmaster@modulix.net

Commentaires, suggestions et autres remarques sur ce service de préférence
sur cette liste.

Qu'en pensez-vous ?
--
Ivan Havlicek

--
gentoo-user-fr@gentoo.org mailing list
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2
Avatar
Yannick Loiseau
Ouai, ca peut etre utile pour avoir une machine rapidement
fonctionnelle. Cependant, je trouve que l'intéret de Gentoo est
justement de pouvoir régler finement les options de compilation, pour
les fonctions incluses, l'optimisation pour la machine, etc.
L'utilisation de binaires fait perdre cet avantage. Bref, c'est pas le
genre de truc que j'utiliserais. Mais pour les pressés qui ont les
options standards, pourquoi pas. Bonne idée donc.

Ivan Havlicek wrote:
Bonjour,
Commentaires, suggestions et autres remarques sur ce service de préférence
sur cette liste.

Qu'en pensez-vous ?


--
mailing list
Avatar
Ivan Havlicek
Yannick Loiseau a écrit :

Ouai, ca peut etre utile pour avoir une machine rapidement
fonctionnelle. Cependant, je trouve que l'intéret de Gentoo est
justement de pouvoir régler finement les options de compilation, pour
les fonctions incluses, l'optimisation pour la machine, etc.




Ce système n'enlève rien à l'intêret de Gentoo, bien au contraire,
c'est une fonctionnalité de portage malheureusement méconnue.
C'est bien pour cette raison qu'il y a un répertoire de binaires
par type de processeur (pour que l'optimisation par machine existe bien).

Pour ce qui est des USE flags, nous essayons toujours d'activer
la plupart des options. De cette manière, il ne te reste à "compiler"
localement que les paquets liés à un matériel spécifique
(VIDEO_CARDS par ex) et ceux où tu veux utiliser des options
différentes de celui qui a crée le paquet binaire.

# emerge --verbose --getbinpkg --usepkg --pretend --newuse --update
--deep world

Va te donner la liste des paquets que tu peux obtenir en binaire,
et ceux que tu va être obligé de compiler toi-même. Soit par ce qu'ils
ne sont
pas disponibles soit, justement que tes USE flags sont différents.

Il n'y a aucune perte de souplesse ni d'optimisation !
(j'y suis moi-même très attaché ;-)
--
Ivan Havlicek

--
mailing list
Avatar
Yannick Loiseau
Ivan Havlicek wrote:
Il n'y a aucune perte de souplesse ni d'optimisation !
(j'y suis moi-même très attaché ;-)



globalement, non, je suis d'accord. C'est juste l'interet. Si 80% du
temps t'as pas les memes USE que la version binaire, l'interet du truc
est limité. Apres je conteste pas que ca peut etre interessant.

Pour ce qui est des USE flags, nous essayons toujours d'activer
la plupart des options.



Justement, on se retrouve alors dans le cas des autres distribs où tout
est inclue. Ce qui me plais dans Gentoo, c'est justement de mettre que
le strict minimum répondant à mes besoins. Apres, c'est une histoire de
gouts, ca se discute pas :)

Comme j'ai dis, c'est une bonne initiative. Ca augmente le choix de la
manière d'utiliser sa Gentoo. Apres, c'est si on en vient a changer ses
uses pour coller a la version binaire qu'on pert la "liberté" de la
compilation dans gentoo. Si effectivement, on utilise les binaires que
lorsqu'ils collent à la config, et que c'est majoritairement le cas,
c'est là que ca deviens vraiment utile.

A ce propos, une suggestion (j'ai pas regardé le dépot hein, c'est peut
etre le cas), mais une séparation desktop/serveur pourrait aussi etre
pas mal, ne serait-ce que pour avoir une version -X et une version X
(perso, mon serveur a meme pas d'ecran, donc pas de X, et je pense pas
etre le seul :)
--
mailing list
Avatar
Damien THEBAULT
--=-5GtdclK1cj133DZdWBxe
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Le mercredi 26 juillet 2006 à 15:01 +0200, Ivan Havlicek a écrit :
[...]

=> http://rsync4.fr.gentoo.org/grp/

[...]

# (PROC_TYPE actuellement disponibles : "c7 pentium3 pentium4 pentium4m
athlon64" )

[...]

Qu'en pensez-vous ?




Personnellement je trouve ça vraiment bien, je connais cette
fonctionnalité de portage depuis longtemps, mais malheuresement je n'ai
jusqu'ici vu aucun serveur proposant de tels paquets.
À mon avis c'est un avantage certain, qui permet de nombreuses choses,
notamment l'utilisation de ces paquets binaires lorsqu'il devient
impossible de compiler (erreur de gcc, automake/conf, ld&co) ou même
lorsque presque tout est cassé (glibc...).
De plus, cela permet d'avoir en très peu de temps un système fonctionne l
(après si on veut optimiser avec ses options, on peut emerge -e world,
ou bien juste laisser les mises à jour faire le travail petit à petit)

Par contre, au niveau des architectures proposées, moi j'aurais plutôt
vu le prolongement de ce qui est proposé sur les live-CDs (x86+i686...).

Mais cela n'enlève rien au mérite de ce projet ;)

D'ailleurs je ne sais pas si il y a une bonne documentation à propos de
toutes les possibilités offertes mais ça serait intéressant à mon a vis.

--
Damien Thebault

Key C15AB8AF
Fingerprint 8FB9 8576 7033 4B45 3DF5 88E8 5471 1A44 C15A B8AF

--=-5GtdclK1cj133DZdWBxe
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Ceci est une partie de message
=?ISO-8859-1?Q?numériquement?= =?ISO-8859-1?Q?_signée?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQBEx+pBVHEaRMFauK8RAuNmAJ0cpCEU7c6YW3XgMqDTT5bxPqQqGACeOhC3
su4kFPVAvwrbqbMDU2zsa7Q ªJp
-----END PGP SIGNATURE-----

--=-5GtdclK1cj133DZdWBxe--

--
mailing list
Avatar
Stephane Bortzmeyer
On Wed, Jul 26, 2006 at 03:01:12PM +0200,
Ivan Havlicek wrote
a message of 44 lines which said:

Si vous en avez assez d'attendre les résultats de compilation,



Oui ! (Mais le service actuel est assez lent, aussi, mais au moins ce
ne sont pas mes ventilos qui travaillent, ce qui est appréciable en
région parisienne en ce moment.)

Cela fait un mois que nous utilisons ce système qui permet de
récupérer des paquets déjà compilés, en particulier pour mettre à
jour nos serveurs d'hébergement.



Quels sont les paquetages présents ? J'ai testé et ça marche bien pour :

- vixie-cron

mais pas ("There are no packages available to satisfy") pour :

- postfix
- sudo
- openslp (demané par gnupg)

Commentaires, suggestions et autres remarques sur ce service de
préférence sur cette liste.



Y a t-il un moyen, au cas où le paquetage binaire ne soit pas présent,
de basculer automatiquement sur la méthode classique ? Quelque chose
comme :

install() {
pkg=$1
emerge --getbinpkgonly --usepkgonly $pkg || emerge $pkg
}

Autre question : pourquoi emerge installe t-il le paquetage s'il estd
déjà installé ? Si je tape "emerge --getbinpkgonly --usepkgonly $pkg"
deux fois de suite, il réinstalle:-(

--
mailing list
Avatar
Ivan Havlicek
Yannick Loiseau a écrit :

globalement, non, je suis d'accord. C'est juste l'interet. Si 80% du
temps t'as pas les memes USE que la version binaire, l'interet du truc
est limité. Apres je conteste pas que ca peut etre interessant.



C'est effectivement limité aux paquets qui ont les même USE,
j'ai cependant constaté une proportion inverse (75% ok).

Comme j'ai dis, c'est une bonne initiative. Ca augmente le choix de la
manière d'utiliser sa Gentoo. Apres, c'est si on en vient a changer ses
uses pour coller a la version binaire qu'on pert la "liberté" de la
compilation dans gentoo. Si effectivement, on utilise les binaires que
lorsqu'ils collent à la config, et que c'est majoritairement le cas,
c'est là que ca deviens vraiment utile.



On est toujours dans le deuxième cas, il faut bien comprendre
qu'emerge ne va te proposer du binaire QUE si tes USE sont
identiques. C'est totalement automatique et transparent.
Tu ne peux en aucun cas "perdre ta liberté de compilation".
C'est simplement une astuce supplémentaire (genre ccache)
qui permet de gagner du temps ;-)

A ce propos, une suggestion (j'ai pas regardé le dépot hein, c'est peut
etre le cas), mais une séparation desktop/serveur pourrait aussi etre
pas mal, ne serait-ce que pour avoir une version -X et une version X
(perso, mon serveur a meme pas d'ecran, donc pas de X, et je pense pas
etre le seul :)



Cela me semble une très bonne idée, cela permetterait un "taux
de recouvrement" (paquets bin avec mêmes USE) bien meilleur.
Je pense pouvoir modifier rapidement l'arborescence pour ajouter
une subdivision au niveau le plus haut :
grp/sansXorg/
grp/avecXorg/
(plutôt que server/desktop car j'ai des serveurs qui ont X11)
Je me demande s'il ne faudrait pas aussi différencier KDE et Gnome.

Je suis aussi en train de préparer un système d'authentification qui
permette à ceux qui le désirent de contribuer en uploadant
les paquets qu'ils ont compilés sur leur machine (FEATURES="buildpkg")
--
Ivan
--
mailing list
Avatar
Yannick Loiseau
Ivan Havlicek wrote:

On est toujours dans le deuxième cas, il faut bien comprendre
qu'emerge ne va te proposer du binaire QUE si tes USE sont
identiques. C'est totalement automatique et transparent.



ca j'ai bien compris, c'est le taux de recouvrement qui "m'inquiete" le
plus.

Tu ne peux en aucun cas "perdre ta liberté de compilation".
C'est simplement une astuce supplémentaire (genre ccache)
qui permet de gagner du temps ;-)



oui, quand je parle de "perdre la liberté", c'est une formule un peu
forte, pour marquer ;)


Je me demande s'il ne faudrait pas aussi différencier KDE et Gnome.



J'y avais pensé après avoir posté :)
C'est ce que je voulais dire avec le "taux de couverture". Ca fait déjà
trois subdivisions (arch, X, KDE/Gnome/Xfce...) ca peut aller loin. Ce
serais d'alleur interessant de faire des stats sur les USEs les plus
utilisés, ne serait-ce que pour voir ou on se classe (config typique ou
utilisation plus customisée)
Mais reflexion faite, meme s'il n'y a que quelques paquets qui collent,
si c'est ceux qui mettent trois plombes à compiler, ça peut valoir le coup.

--
mailing list
Avatar
Jean-François Maeyhieux
--=-WYs0EVbUQY4vgGU59Ry3
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

On Thu, 2006-07-27 at 16:23 +0200, Ivan Havlicek wrote:

Cela me semble une très bonne idée, cela permetterait un "taux
de recouvrement" (paquets bin avec mêmes USE) bien meilleur.
Je pense pouvoir modifier rapidement l'arborescence pour ajouter
une subdivision au niveau le plus haut :
grp/sansXorg/
grp/avecXorg/
(plutôt que server/desktop car j'ai des serveurs qui ont X11)
Je me demande s'il ne faudrait pas aussi différencier KDE et Gnome.

Je suis aussi en train de préparer un système d'authentification qui
permette à ceux qui le désirent de contribuer en uploadant
les paquets qu'ils ont compilés sur leur machine (FEATURES="buildpkg" )
--
Ivan



J'ai suivi le fil de la discussion en entier sans avoir le temps d'y
répondre.
Le principe de faire un serveur de packages binaires est excellent, j'y
ai pensé à maintes reprises et je suis toujours resté sur le problè me de
recouvrement des USE flags utilisés. En effet, si on s'amuse à calculer
la couverture du nombre de possiblité des packages avec toutes les
combinaisons de USE flags, plus le nombre d'architectures différentes,
cela revient rapidement à des nombres de compilation et des capacités d e
stockage impressionnants. Néanmoins une grosse architecture réseau avec
utilisation massive de distcc pour la compilation et aggrégation de
l'espace de stockage pourrait permettre d'y venir à bout. Je ne parle
même pas des problèmes de bande passante que cela donnerait car un tel
système serait massivement choisi par les utilisateurs je pense,
notamment à l'installation où les temps de compilation sont importants
et freine pour beaucoup l'utilisation de gentoo en tant que serveur.


Donc, la problématique de pouvoir avoir tous les pkgs compilés avec
toutes les combinaisons de USE flags pour avoir une couverture de 100%
se résume en trois points:

1) La puissance et le temps de compilation nécessaire.
2) La capacité de stockage.
3) La bande passante nécessaire.


Et là j'ai une petite idée qui me trotte dans la tête depuis plus d'u n
an (je suis sur gentoo depuis la version 1.2):

1) Le problème des temps de compilation peut être déporté sur les
utilisateurs étant donné qu'à la base, gentoo fonctionne sur le princ ipe
que chacun compile pour ses besoins.
2) et 3) La capacité de stockage et la bande passante peuvent être
deportés d'une architecture centralisé sur une architecture P2P
permettant de résoudre le problème de bande passante et de capacité d e
stockage d'un seul coup.

En conclusion, ne serait il pas fortement intéressant de créer un
serveur P2P (bittorent ? un serveur edonkey ?) auquel chaque utilisateur
partagerait ses packages binaires, ce qui dans la pratique permettrait
d'approcher une couverture maximale sans forcément atteindre la
couverture totale... Le P2P faisant office par son fonctionnement même
de système statistique pour les differentes architectures et combinaison
de USE FLAGS.

Bon dans la pratique ca semble jouable mais il reste un gros problème:
le nommage des packages compilés car autant un package compilé
différement (arch+use) aurait un hash différent ce qui permettrait de
les différencier, rien ne pourrait les différencier par contre au nivea u
du nom, ce qui poserait un problème pour greffer un tel système à
portage... Mais là n'ayant jamais pratiqué d'installation par packages
binaires, je ne sais pas comment portage réagit pour faire la différenc e
entre les architectures et les USE flags.

Je suis curieux d'avoir votre avis la dessus, car je pense que la
communauté entière gentoo aurait un intêret énorme à fonctionner sur un
tel modèle... Economie d'energie à grande echelle, économie de bande
passante et rapidité
d'installation serait au rendez vous....


Voili voilou, en espérant ne pas avoir dis de grosses boulettes ! ;o)


Zentoo


--
--------------------------------------------------------------------------- -----------
Jean-François Maeyhieux
--------------------------------------------------------------------------- -----------
PGP Public Key - Key ID = 63DB4770 Tuttle (JFM)
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x63DB4770
--------------------------------------------------------------------------- -----------

--=-WYs0EVbUQY4vgGU59Ry3
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQBEyjb4HVRy9WPbR3ARAgPaAJ4oKlI+S+/KKB/PmDAJYlbanwrCyQCeLm9L
sDDVjTb/KIhcPi+C53MRcT0 =+Qdz
-----END PGP SIGNATURE-----

--=-WYs0EVbUQY4vgGU59Ry3--

--
mailing list
Avatar
Aurélien Francillon
On Friday 28 July 2006 18:10, Jean-François Maeyhieux wrote:
On Thu, 2006-07-27 at 16:23 +0200, Ivan Havlicek wrote:
> Cela me semble une très bonne idée, cela permetterait un "taux
> de recouvrement" (paquets bin avec mêmes USE) bien meilleur.
> Je pense pouvoir modifier rapidement l'arborescence pour ajouter
> une subdivision au niveau le plus haut :
> grp/sansXorg/
> grp/avecXorg/
> (plutôt que server/desktop car j'ai des serveurs qui ont X11)
> Je me demande s'il ne faudrait pas aussi différencier KDE et Gnome.
>
> Je suis aussi en train de préparer un système d'authentification qui
> permette à ceux qui le désirent de contribuer en uploadant
> les paquets qu'ils ont compilés sur leur machine (FEATURES="buildpkg")
> --
> Ivan




...

Bon dans la pratique ca semble jouable mais il reste un gros problème:
le nommage des packages compilés


...

Tu peux ajouter un deuxiemme gros probleme: la securité de tout ca ...

Coment peut tu etre sur que le package binnaire que tu télécharge ne
contiendra pas de virus, chevaux de troie, rootkit ou autres friandises ?

Faire confiance aux dev gentoo et aux serveurs rsync on a pas trop le choix
et semble plutot raisonable. Ca sera mieux quand le systeme de verification de
signatures sera mis en place

Faire confiance a quelques personnes bien identifiées qui administrent un
serveur de packages binnaires semble etre acceptable pour certains ...
au pire si on trouve un jour une saleté ajoutée dans un pkg on sait "sur qui
tapper"

Faire confiance a nimporte qui sur un reseau P2P de distribution de packages
binaires ... avec potentiellemnt des milliers de contributeurs ca me semble
de la folie ! Ca devient vraiment trop facile de prendre le controle d'une
pachine a distance ;) A moins d'avoir un systeme de gestion de "reputation"
et des signatures GPG ... mais c'est pas simple a mettre en oeuvre...

Aurélien



--
mailing list
Avatar
Jean-François Maeyhieux
--=-22itR9+0nIxK80kiVdh2
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

On Fri, 2006-07-28 at 18:34 +0200, Aurélien Francillon wrote:

Tu peux ajouter un deuxiemme gros probleme: la securité de tout ca ...

Coment peut tu etre sur que le package binnaire que tu télécharge ne
contiendra pas de virus, chevaux de troie, rootkit ou autres friandises ?

Faire confiance aux dev gentoo et aux serveurs rsync on a pas trop le cho ix
et semble plutot raisonable. Ca sera mieux quand le systeme de verificati on de
signatures sera mis en place

Faire confiance a quelques personnes bien identifiées qui administrent un
serveur de packages binnaires semble etre acceptable pour certains ...
au pire si on trouve un jour une saleté ajoutée dans un pkg on sait " sur qui
tapper"

Faire confiance a nimporte qui sur un reseau P2P de distribution de packa ges
binaires ... avec potentiellemnt des milliers de contributeurs ca me semb le
de la folie ! Ca devient vraiment trop facile de prendre le controle d'un e
pachine a distance ;) A moins d'avoir un systeme de gestion de "reputati on"
et des signatures GPG ... mais c'est pas simple a mettre en oeuvre...

Aurélien




Le problème de la sécurité est évident, je te l'accorde mais il se rait
possible de vérifier l'authenticité d'un paquet binaire en le mettant à
disposition sur le P2P
soit en mettant en place un système d'authentification des fournisseurs
de pkgs soit tout simplement par élimination des paquets binaires
n'ayant pas un nombre de fournisseurs différents jugés comme suffisant.
C'est à creuser mais cela me semble pas insurmontable. Et pourquoi pas
valider les hashcodes des paquets par les devs gentoo ou créer une
entité gentoo pour cela...

Zentoo

--
--------------------------------------------------------------------------- -----------
Jean-François Maeyhieux
--------------------------------------------------------------------------- -----------
PGP Public Key - Key ID = 63DB4770 Tuttle (JFM)
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x63DB4770
--------------------------------------------------------------------------- -----------

--=-22itR9+0nIxK80kiVdh2
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQBEyj7kHVRy9WPbR3ARAnydAKDLkE0ovCpOqkB+peD2RId+VrSKRACfRD7+
Tx42SIIXmBdKiPZ8yZCD550 =LPN2
-----END PGP SIGNATURE-----

--=-22itR9+0nIxK80kiVdh2--

--
mailing list
1 2