Bon, vu que j'ai traîné pour retrouver le nom de make-kpkg, je m'étais temporairement rabattu sur apt-build pour connaître moi aussi, la griserie de la compilation.
Pour ceux qui ne connaissent pas l'outil, il s'agit d'un utilitaire Debian, développé principalement par Julien Danjou, qui permet de re-compiler avec des options plus pointues (par défaut, -sO3 par exemple) les paquets sources correspondants aux binaires des archives Debian.
C'est un peu une option de gentoïsation (pour mémoire, Gentoo n'est pas la seule Distribution source, je pense à Lunar-Linux ou à LFS ;) pour les Debianneux équipés d'ordinateurs récents qui sous-utilisent leur processeur en permanence.
Une bonne introduction pour ceux qui découvriraient l'engin :
http://www.andesi.org/index.php?node=108
Amusant : le succès planétaire qu'a rencontré ce tutorial rédigé par un autre Julien, Julien Reveret, dont j'ai rencontré 3 ou 4 traductions en langues différentes.
[EN] http://julien.danjou.info/article-apt-build.html (traduction J. Danjou)
[PU] http://grajagan.rg3.net/artigo-apt-build.html (traduction T. Scherer)
[RU] http://www.digitalhardcore.us/apt-build-doc/apt-build-ru.htm (traduction V. Ignatenko)
Plusieurs remarques :
- la page man ne ment pas : le programme est encore correctement buggué.
http://www.delafond.org/traducmanfr/deb/man1/apt-build.1.htm(...)
Certaines compilations achoppent ainsi, brutalement, sans grande explication, parfois c'est l'option '--reinstall' qui ne donne rien (refus de compiler).
Plus drôle (grave ?), comme certains l'ont relevé dans des forums anglophones, il n'est pas sûr que les bonnes options de compilation soit toujours passées à GCC !
- il ne faut pas hésiter à modifier le fichier apt-build.conf, notamment si vous avez l'idée farfelue de compiler OOo "pour voir". Renseignement pris, il faut compter 5 Go de disponible pour se lancer dans l'aventure (+ un gros stock de darjeeling + "Les Thibault" de R. Martin du Gard). Une partition très spacieuse s'imposera vite plutôt qu'un "/" malingre...
- les résultats en terme de performance sont aléatoires : VLC me semble beaucoup plus tonique (pas forcément étonnant : le moteur doit profiter des optimisations proc) alors que synaptic est sensiblement plus mollason. Cela tient peut-être au fait que les choix de compilation détaillés du packageur Debian sont préservés, ce qui limite peut-être l'effet positif de la compilation.
- Synaptic y perd un peu son latin : il n'est pas évident de savoir d'où vient le logiciel installé : forcément les numéros de version sont parfaitement identiques !!
Et vous, qu'en pensez-vous ?
Yoj'
Journal apt-build : gadget ou pas ? votre avis à vous ?!
2
déc.
2005
# bof
Posté par Mr F . Évalué à 10.
[^] # Re: bof
Posté par Louis Nyffenegger . Évalué à -2.
La plupart des distributions fournissent un noyau pré-compilé mais l'on n'a pas le .config ni la totalité des sources du noyau utilisé (il est d'ailleurs difficile de récupèrer une version du noyau customisé par telle ou telle distribution concordant avec le noyau actuel).
Or ces quelques fichiers sont indispensables pour l'ajout de certains drivers ou logiciels (je pense à vmware entre autres).
Sinon, pour gentoo (que j'utilise), l'intérêt (pour moi) se situe dans le fait que gentoo n'utilise pas de script post-install (contrairement à debian), ce qui a l'avantage de ne pas faire des choses dont l'on a pas forcément besoin (ajout de certains programmes au démarrage par exemple...).
[^] # Re: bof
Posté par Ben (site web personnel) . Évalué à 8.
Euh.. depuis le 2.6 le .config est conservé dans /proc, et de plus une bonne distrib pose toujours le .config dans /boot/config`uname -a`
aussi, sous debian (et ubuntu) lorsque les noyaux sont customisé, ils sont livrés séparés de leur patches (par apt-get source) qui sont appliqués à postériori. Bref, tout cela pour dire qu'il n'est pas difficile de retrouver les sources exactes de son noyau packagé.
Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie
[^] # Re: bof
Posté par Yusei (Mastodon) . Évalué à 8.
Ce n'est pas la recompilation qui optimise les programmes, c'est le fait de recompiler en spécifiant d'utiliser des optimisations pour son architecture. Et c'est un fait, ça optimise les programmes. Ce qui est douteux, c'est que le gain soit sensible dans la vie de tous les jours.
Par contre, quelque chose me dit qu'avec l'arrivée des processeurs de type Cell ou autre, ça va devenir vraiment intéressant pour le compilateur de savoir quelle est l'architecture utilisée.
[^] # Re: bof
Posté par briaeros007 . Évalué à 1.
le fait de pouvoir specifié les dependance permet d'optimiser la mémoire !
pas besoin de compiler le support pour gnome si on ne l'utilise pas ;)
[^] # Re: bof
Posté par Yusei (Mastodon) . Évalué à 7.
Sur les grosses machines qui n'ont pas peur de compiler KDE en entier, ce n'est pas l'économie de quelques Mo de code qui va changer grand chose niveau performances. En dehors du fait d'être persuadé d'avoir un système optimal, ce qui se défend :)
[^] # Re: bof
Posté par Louis Nyffenegger . Évalué à 5.
[^] # Re: bof
Posté par Bruno Adele (site web personnel) . Évalué à 1.
J'utilisé debian entre 1999-2004, c'etait une distribution excelente (ca l'est toujours d'ailleur). Mais à mon sens elle n'évolué pas assez vite coté desktop.
J'ai donc essayer gentoo, et il est vraie que ce que j'aime bien dans cette distrib, c'est sa réactivité, les paquets sorte assez rapidement, et vous pouvez meme vous créer facilement des paquets, par exemple voir mes paquets ( http://www.jesuislibre.org/projets/gentoo )
Mais il est vrai que des fois c'est assez barbant de metre à jours son OS, par exemple juste pour une mise à jours KDE 3.5, il se met à compiler 250 paquets
Mais j'insiste, cette distrib est vachement maniable, et elle est à essayer !
[^] # Re: bof
Posté par Yusei (Mastodon) . Évalué à 7.
Juste pour info, les packages Debian sont faciles aussi à faire soi même, avec l'aide des outils livrés en standard. Le plus souvent, il suffit de lancer un script, éditer la description du paquet et de copyright, et les règles de construction. Si le logiciel à packager utilise autotools ou des makefiles propres, il n'y a pratiquement rien à faire d'autre qu'entrer la description du paquet.
Bref, c'est comme la compilation de noyau: au début ça fait peur, et en fait c'est tout bête.
[^] # Re: bof
Posté par un_brice (site web personnel) . Évalué à 4.
Pour en revenir au sujet de départ, je trouve que l'interêt de compiler ses paquets est d'être libre des dépendances binaires, beaucoup plus strictes. Par exemple je peut figer (une ligne dans portage.mask) php à la version 4.1, ou passer à kde 3.5, sans que ça n'exprime des contraintes sur la version de ma glibc ou de quelque autre composant plus critique.
Autre exemple : installer xine implique d'installer des librairie de Gnome sous debian, parce que sinon les gnomistes ne pourraient pas accèder aux fonctionalités dont ils ont besoin (c'est d'autant plus dérangeant que Xine est necessaire à KDE). Sous gentoo un "useflag" (mot clef à mettre où non dans un fichier) adapte dynamiquement les dépendances aux habitudes de l'utilisateur.
De manière plus générale, ça permet de proposer à ceux qui les veulent des fonctionalités qu'on ne pourrait pas imposer à tout le monde.
(et le gain de perfs est à priori réel, par rapport à des binaires 386 - 686 je dit pas par contre)
[^] # Re: bof
Posté par Mr F . Évalué à 3.
Crois moi, quand on passe son temps à customiser des serveurs, on a pas du tout envie de customiser sa Workstation, on veut que ça marche et c'est tout.
Et je ne suis de toute manière pas convaincu de la pérennité d'une Gentoo sur le long terme.
[^] # Re: bof
Posté par un_brice (site web personnel) . Évalué à 2.
Je le fait parce que ça m'amuse mais ce n'est pas une nécessité. Un "emerge sync && emerge -uvD world;etc-config" toutes les semaines suffirait (suffit à mon serveur en fait). J'estime le temps d'interaction avec la machine à dix minutes dans ce cas.
À d'autres ! J'utilise des distros sources depuis mes débuts, à peu près à la même époque que toi.
D'ailleurs je connais plus de gens qui font le passage dans le sens binaire vers source que le contraire.
Justement !
Un type qui upgrade sa glibc et/ou casse tout son arbre de dépendance (ce qui se passe à l'heure actuelle sous debian si tu installe kde 3.5) perds beaucoup plus de temps qu'un gars qui lance un "emerge kde-meta" avant d'aller se coucher.
Utiliser une distro source augmente le temps d'installation initial de la plupart des logiciels, mais réduit l'interaction nécessaire avec la machine.
Et à moyen terme, le contrecoût disparait : en cas de mise à jour tu a plus vite fait de compiler toi même que d'attendre que le mainteneur sorte son paquet (au mieux, il va aussi vite que toi à compiler, en pratique beaucoup moins). Alors c'est ton CPU qui bosse, mais avec un nice de 20 (NICENESS dans le make.conf) ça se voit même pas (sauf sur les portables).
Les miennes se portent bien, depuis quelques années déjà.
Sous gentoo, virer les dépendances à gnome me prend 16 secondes, montre en main (je viens de faire le test, il inclut la phase de login).
[^] # Re: bof
Posté par Mr F . Évalué à 2.
Tout à fait, mais il n'est pas necessaire d'utiliser une distro source pour cela, je le fais régulièrement sur des distro binaire.
Je le fait parce que ça m'amuse mais ce n'est pas une nécessité. Un "emerge sync && emerge -uvD world;etc-config" toutes les semaines suffirait (suffit à mon serveur en fait). J'estime le temps d'interaction avec la machine à dix minutes dans ce cas.
Tout à fait, mais en ce cas tu n'optimise et ne personnalise rien du tout, autant ne pas recompiler, finalement...
À d'autres ! J'utilise des distros sources depuis mes débuts, à peu près à la même époque que toi.
Mes début ? Basé sur quoi ? Mon inscription Linuxfr ? C'est une mauvaise base, ma première installation de Linux, certes très laborieuse, date de 1998.
D'ailleurs je connais plus de gens qui font le passage dans le sens binaire vers source que le contraire.
Moi non :-)
Justement !
Un type qui upgrade sa glibc et/ou casse tout son arbre de dépendance (ce qui se passe à l'heure actuelle sous debian si tu installe kde 3.5) perds beaucoup plus de temps qu'un gars qui lance un "emerge kde-meta" avant d'aller se coucher.
Et ça prendra plus de temps que quelqu'un restant en 3.4 (ou 3.3)... Mais certe, Debian n'est pas une distribution pour avoir la toute dernière version d'un soft "dans la minute". Mais ça, c'est de l'amusement, rien d'autre.
Les miennes se portent bien, depuis quelques années déjà.
Parceque tu en prend soins :-)
Sous gentoo, virer les dépendances à gnome me prend 16 secondes, montre en main (je viens de faire le test, il inclut la phase de login).
En comptant la recompilation ?
[^] # Re: bof
Posté par un_brice (site web personnel) . Évalué à 2.
Et je doute très fortement que tu ait mis en place selinux sur une debian en moins d'un mois de travail intensif. Des choses, parmis tant d'autres, qui ne sont pas necessaires avec des distributions sources (et qui ne sont que des exemples).
Admettons. Il reste que j'utilise des distros sources depuis assez longtemps pour que l'attrait de la nouveauté ai fini de jouer.
Non, je voulais pouvoir utiliser Konqueror pour aller sur Gmail et les filtres KMail par imap, plus la webcam.
Pareil pour selinux, ssp, Jabber2 sur amd64... ce sont des choses qui nécessitent de compiler et qui sont utiles.
D'ailleurs il ne s'agit souvent pas de minutes mais d'années avec debian stable, et de 6 mois en testing. Et ceci à cause du lien fort qui existe entre les versions des packages utilisateurs et du coeur du système, sur toutes les distributions binaires.
Je ne vois pas ce que tu veut dire. Sur mon serveur je ne fait plus que les mises à jour réglementaires.
Non, je ne compte que le temps d'interaction avec la machine que l'opération me coute. Et ce temps est très court sous gentoo.
Le reste ne corresponds pas à un compromis que j'aurais à faire. Que ma machine compile ou se repose, c'est son problème: elle marche et ça me suffit.
[^] # Re: bof
Posté par Mr F . Évalué à 2.
Bien sûr, je fais ça à la façon Debian, ce serait idiot de faire autrement. Il reste du travail concernant la mise à jour, bien sûr.
Non, je voulais pouvoir utiliser Konqueror pour aller sur Gmail et les filtres KMail par imap, plus la webcam.
Pareil pour selinux, ssp, Jabber2 sur amd64... ce sont des choses qui nécessitent de compiler et qui sont utiles.
Ok, je te l'accorde, il y a quelques fonctionnalités intéressantes qui necessite une version récente d'un logiciel.
D'ailleurs il ne s'agit souvent pas de minutes mais d'années avec debian stable, et de 6 mois en testing. Et ceci à cause du lien fort qui existe entre les versions des packages utilisateurs et du coeur du système, sur toutes les distributions binaires.
La volonté de Debian Stable n'a jamais été d'avoir els derniers logiciel mais d'avoir une version stable d'un ensemble de logiciel. Il ne faut pas non plus critiquer Debian sur ce point la qui justement est voulu.
En Testing, c'est généralement 14 jours, sauf cas effectivement de changements importants. Sur SID, c'est plus rapide.
Non, je ne compte que le temps d'interaction avec la machine que l'opération me coute. Et ce temps est très court sous gentoo.
Le reste ne corresponds pas à un compromis que j'aurais à faire. Que ma machine compile ou se repose, c'est son problème: elle marche et ça me suffit.
Oui, mais si tu veux installer un logiciel customisé, bien que cela te prenne a toi 16 secondes (en sachant faire) il faudra attendre la fin de la compilation. Et donc tu ne pourra utiliser le logiciel que *plus tard*. Et ça, pour des actions imédiates, c'est très pénibles.
# Ma vie à moi
Posté par Amand Tihon (site web personnel) . Évalué à 5.
Dans ces cas-là, je suis plutôt adepte de dpkg-buildpackage, précédé d'un "dch -v blabla". Comme version, je donne habituellement un truc très légèrement plus grand que la version debian actuelle, pour qu'il ne soit automatiquement installé que si quelque chose de neuf arrive officiellement.
Un bon choix dans la version (un meilleur choix que "blabla" en tout cas) permet de prévoir de manière assez fine le comportement du paquet maison.
- Je veux, lorsque la version 2.0 arrive, mais pas avant, que le paquet officiel remplace le mien : je mets 1.9.9-0.alrj.1
- Ça concerne un bug que j'ai reporté, et l'auteur m'a affirmé que ce serait résolu dans le prochain upload : j'ajoute juste .alrj.1 à la version officielle (1.2.3-4 -> 1.2.3-4.alrj.1)
De manière générale, toutes les versions de mes paquets contiennent "alrj' dans la partie concernant la révision, ça permet de voir rapidement si c'est un paquet maison ou non.
Mais je ne m'amuse pas à compiler tous mes paquets pour les optimiser : en x86_64, il n'y a pas un lourd passé avec lequel il faut rester compatible :)
# Quelques precisions
Posté par Julien Danjou (site web personnel) . Évalué à 10.
C'est vrai :-)
Certaines compilations achoppent ainsi, brutalement, sans grande explication, parfois c'est l'option '--reinstall' qui ne donne rien (refus de compiler).
Il y a plusieurs bugs reportes a ce sujet, voir http://bugs.debian.org/apt-build
Pour l'instant l'origine est floue, et je n'ai pas le temps d'investiguer
Plus drôle (grave ?), comme certains l'ont relevé dans des forums anglophones, il n'est pas sûr que les bonnes options de compilation soit toujours passées à GCC !
Ca c'est un probleme recurent chez les gens qui ne lisent pas les README.Debian et qui croient ce que make affiche sur leurs ecrans. Mais dans la plupart des cas, les options sont correctes. Faites moi confiance. ;-)
# et apt-get build-dep alors !?
Posté par Ben (site web personnel) . Évalué à 6.
Et apt-get build-dep alors ! personne ne connais ?
Serait-ce une particularité de la sid et de l'ubuntu ?
Tout homme qui dirige, qui fait quelque chose, a contre lui ceux qui voudraient faire la même chose, ceux qui font précisément le contraire, et surtout la grande armée des gens d'autant plus sévères qu'ils ne font rien du tout. -- Jules Claretie
[^] # Re: et apt-get build-dep alors !?
Posté par Skanx (site web personnel) . Évalué à 2.
[^] # Re: et apt-get build-dep alors !?
Posté par niol (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.