Journal apt-build : gadget ou pas ? votre avis à vous ?!

Posté par .
Tags : aucun
0
2
déc.
2005
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'
  • # bof

    Posté par . Évalué à 10.

    Moi j'en pense que recompiler ne sert à rien d'autre que s'amuser ou perdre du temps, au choix. Il n'a jamais, et il ne le sera probablement jamais, été prouvé que la recompilation pouvait optimiser des programmes. Excepté peut être les player vidéo.
    • [^] # Re: bof

      Posté par . Évalué à -2.

      L'intérêt de la compilation se situe surtout au niveau du noyau...

      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 (page perso) . Évalué à 8.

        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).

        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 . Évalué à 8.

      Il n'a jamais, et il ne le sera probablement jamais, été prouvé que la recompilation pouvait optimiser des programmes.

      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 . Évalué à 1.

        je suis pas totalement d'accord , car meme si l'optimisation du code par le proc sur les x86 n'est pas encore optimal,
        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 . Évalué à 7.

          C'est vrai, mais malheureusement les machines sur lesquelles on voudrait économiser des cycles et de la mémoire sont généralement des machines sur lesquelles on n'a pas envie de lancer une grosse compilation, sous peine d'y passer des jours.

          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 . Évalué à 5.

            On peut utiliser distcc qui va permettre de compiler sur une machine un peu plus puissante.
    • [^] # Re: bof

      Posté par (page perso) . Évalué à 1.

      Euh, je suis partiellement d'accord avec toi.

      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 . Évalué à 7.

        [avec Gentoo] vous pouvez meme vous créer facilement des paquets

        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 (page perso) . Évalué à 4.

          Juste pour info, les packages Debian sont faciles aussi à faire soi même
          Ça n'a rien à voir. Pour info, voilà le paquet de kompose : http://gonzui.gentoo.gr.jp/gonzui.cgi/markup/portage/kde-mis(...) et d'apache :

          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 . Évalué à 3.

            C'est bien ce que je dis, ça sert à s'amuser, quand tu en aura marre de passer plusieurs heures par semaine à t'occuper de ton système, tu reviendra, comme beaucoup, vers un système binaire et tu upgradera ta glibc pour avoir kde 3.5 ou tu installera les librairies Gnome, parceque ça sera toujours plus simple et rapide que de customiser son système.

            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 (page perso) . Évalué à 2.

              C'est bien ce que je dis, ça sert à s'amuser
              Ça dépends, on peut avoir besoin de tel ou tel logiciel qui ne seraient pas dans la distrib en version stable (apc, eaccelerator, openoffice2.0), où de certaines fonctionalités (mpm, selinux...).

              quand tu en aura marre de passer plusieurs heures par semaine à t'occuper de ton système
              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.

              tu reviendra, comme beaucoup, vers un système binaire
              À 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.

              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.
              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).

              Et je ne suis de toute manière pas convaincu de la pérennité d'une Gentoo sur le long terme.
              Les miennes se portent bien, depuis quelques années déjà.

              tu installera les librairies Gnome, parceque ça sera toujours plus simple et rapide que de customiser son système
              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 . Évalué à 2.

                Ça dépends, on peut avoir besoin de tel ou tel logiciel qui ne seraient pas dans la distrib en version stable (apc, eaccelerator, openoffice2.0), où de certaines fonctionalités (mpm, selinux...).

                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 (page perso) . Évalué à 2.

                  Ça dépends, on peut avoir besoin de tel ou tel logiciel qui ne seraient pas dans la distrib en version stable (apc, eaccelerator, openoffice2.0), où de certaines fonctionalités (mpm, selinux...).
                  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.
                  Youpi. Donc tu installe en vrac et tu fait les mises à jours à la main. À moi que tu n'ait ton propre dépot ? Il reste que tu doit surveiller les paquets.
                  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).

                  À 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.
                  Admettons. Il reste que j'utilise des distros sources depuis assez longtemps pour que l'attrait de la nouveauté ai fini de jouer.

                  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.
                  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.

                  Les miennes se portent bien, depuis quelques années déjà.
                  Parceque tu en prend soins :-)
                  Je ne vois pas ce que tu veut dire. Sur mon serveur je ne fait plus que les mises à jour réglementaires.

                  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 ?
                  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 . Évalué à 2.

                    Youpi. Donc tu installe en vrac et tu fait les mises à jours à la main. À moi que tu n'ait ton propre dépot ? Il reste que tu doit surveiller les paquets.

                    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 (page perso) . Évalué à 5.

    Quand j'ai besoin de recompiler un paquet debian, c'est normalement parce que les options choisies ne me conviennent pas ou pour installer une nouvelle version mineure, et c'est très rare.

    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 (page perso) . Évalué à 10.

    - la page man ne ment pas : le programme est encore correctement buggué.

    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 (page perso) . Évalué à 6.

    le wiki d'apt-build dit:
    Quand vous voulez repackagez vous même, dpkg-buildpackage ne va pas chercher les dépendances pour vous contrairement à apt-build, et le repackaging peut devenir pénible et demander des connaissances que l'on a pas forcément quand on est pas mainteneur d'un package

    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 (page perso) . Évalué à 2.

      Si le package à compiler dépend de quelques autres packages qui dépendent eux-même de quelques autres packages, sachant qu'il faudra lancer un apt-get build-dep pour chaque, là ça devient assez vite pénible ;)
      • [^] # Re: et apt-get build-dep alors !?

        Posté par (page perso) . Évalué à 2.

        apt-get build-dep installe des binaires il me semble. En gros cà va chercher tous les paquets -dev nécessaire à la compilation d'un paquet particulier, en plus des dépendances. Donc pas de dépendances de compilation à chercher pour chacun d'eux, sauf si tu veux tout recompiler.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.