Les paquets rétroportés (backports) deviennent officiels chez Debian

Posté par  (site web personnel, Mastodon) . Modéré par patrick_g.
Étiquettes :
21
7
sept.
2010
Debian
Pour rappel, les paquets rétroportés (backports) pour Debian sont une solution pour conserver une installation de Debian en version stable tout en allant piocher au cas par cas pour avoir certains paquets plus à jour. Jusqu'à maintenant, les backports étaient maintenus en dehors du cadre officiel de Debian sur le site Backports.org. C'est un dépôt qui date depuis, a minima, le mois d'août 2003.

Depuis le début du mois de septembre, l'archive backport intègre donc officiellement Debian, et sera disponible à l'adresse http://backports.debian.org. Vous trouverez toutes les explications dans la nouvelle parue pour l'occasion.

Visiblement ils ont choisi de faire cela avant la sortie de la prochaine version stable (Squeeze), afin que l'installeur intègre directement les backports comme un dépôt normal.

NdM : Cette dépêche est tirée du journal de ultimat. Merci à lui.

Aller plus loin

  • # Miroir français

    Posté par  . Évalué à 3.

    Ce qui est dommage c'est l'absence de miroir français.

  • # Ce qu'il est important de noter ...

    Posté par  (site web personnel) . Évalué à 6.

    Ce qu'il est important de noter dans cette nouvelle, c'est qu'un service très très intéressant - à savoir la possibilité de sortir du cadre strict des paquets des dépôts stables pour installer des logiciels plus récents et ainsi bénéficier de la puissance de la version stable autour - devient officiellement soutenu par le projet Debian.

    Bien sûr le service était déjà très bien géré et fiable, mais le fait de l'avoir intégré à l'architecture officielle va permettre de généraliser la technique, pour le plus grand bien des utilisateurs. Et je pense que très vite les gens vont être heureux de pouvoir mettre à jour certaines de leurs applis qui évoluent vite tout en restant dans le cadre stable de leur version de Debian.

    • [^] # Re: Ce qu'il est important de noter ...

      Posté par  . Évalué à 3.

      Bien sûr le service était déjà très bien géré et fiable,
      C'est peut-être parce que fiable qu'il a été intégré. (

    • [^] # Re: Ce qu'il est important de noter ...

      Posté par  (site web personnel) . Évalué à 2.

      Parfois, il vaut mieux se tourner vers schroot comme solution. Dernier exemple en date dans mon laboratoire, un utilisateur a besoin de python2.6 avec pas mal de truc autour. J'ai pas vu comment faire cela avec les backports, impossible à faire non plus en mixant lenny et squeeze sans pourrir toute la lenny (dont la libc).

      J'aurais pu faire une machine virtuelle mais au final, schroot est bien plus simple et la surcharge quasi-nulle. Pour l'utilisateur, l'utilisation de schroot est très facile aussi.

    • [^] # Re: Ce qu'il est important de noter ...

      Posté par  (site web personnel) . Évalué à 4.

      Est-ce qu'il y a les mises à jour de sécurité sur les paquets du dépôt backport ?

      • [^] # Re: Ce qu'il est important de noter ...

        Posté par  . Évalué à 3.

        A priori oui, avec des annonces sur la mailing-list http://lists.debian.org/debian-backports-announce/. Dernier exemple en date : http://lists.debian.org/debian-backports-announce/2010/08/ms(...)

        Étienne

        • [^] # Re: Ce qu'il est important de noter ...

          Posté par  (site web personnel) . Évalué à 4.

          Bon je suis allé voir la FAQ sur le site du projet:

          Q: Is there security support for packages from backports.org?

          A: Unfortunately not. This is done on a best effort basis by the people who track the package, usually the ones who originally did upload the package into backports.

          • [^] # Re: Ce qu'il est important de noter ...

            Posté par  (site web personnel) . Évalué à 1.

            Mon expérience par le passé me fait dire qu'il n'y a pas de mise à jour de sécurité régulière. Maintenant que c'est plus officiel, cela peut changer. A voir.

            A noter pour ceux qui ne le savaient pas qu'il faut limiter les paquets provenant du backport au strict minmum et ne pas tout mettre. Personnellement, je fait cela via le fichier preferences d'apt où j'ajoute chaque paquet du backport. C'est pas très souple mais cela marche !

            • [^] # Re: Ce qu'il est important de noter ...

              Posté par  (site web personnel) . Évalué à 5.

              > Personnellement, je fait cela via le fichier preferences d'apt où j'ajoute chaque paquet du backport. C'est pas très souple mais cela marche !

              Aptitude propose également une option -t pour ça. Par exemple :
              aptitude -t lenny-backports install nginx

              • [^] # Re: Ce qu'il est important de noter ...

                Posté par  (site web personnel) . Évalué à 1.

                J'utilise un script lancé par cfengine qui me fait les installations tout seul, et cela sur un parc entier de machine. L'option -t marche aussi avec apt-get. Je le fait la première fois puis je note tous les paquetages provenant de backports, puis je met cela dans mon fichier preferences.

                Ainsi, par la suite, un apt-get dist-upgrade marche aussi ce qui n'est pas le cas si on n'a pas le fichier preferences qui va bien (souvenir).

                Bref, en automatique sur un parc, c'est pas toujours trivial à faire surtout s'il y a pas mal de dépendances (comme open-office). Surtout, j'ai pas trouvé de moyen simple de le faire à part cette méthode un peu bourrin. J'aurais par exemple aimé dans le fichier préférences pouvoir mettre plusieurs noms de paquetages sur la même ligne afin de diminuer le nombre de celles-ci.

                • [^] # Re: Ce qu'il est important de noter ...

                  Posté par  (site web personnel) . Évalué à 2.

                  Je te conseille de lire : http://backports.debian.org/Instructions/

                  Tu y trouveras quelque chose de plus simple pour faire ce que tu fais.

                  • [^] # Re: Ce qu'il est important de noter ...

                    Posté par  (site web personnel) . Évalué à 1.

                    C'est exactement ce que je fait, du pinning dans le fichier preferences...

                    Avec cfengine, j'installe par exemple openoffice sur les postes de travail puis un jour, je veux que cela bascule sur la version backport. Donc si tu veux qu'un apt-get install ou un apt-get dist-upgrade bascule ton openoffice sur backport sans mettre le -t, il faut jouer sur le pinning de tous les paquets qui proviendront du backport, sinon openoffice n'upgrade pas tout seul sur le backport.

                    Encore une fois, je suis prêt à avoir mieux mais j'ai pas trouvé mieux pour gérer de manière automatique (et fiable) un parc entier.

                    • [^] # Re: Ce qu'il est important de noter ...

                      Posté par  (site web personnel) . Évalué à 3.

                      Si je comprends bien ce que tu dis, tu utilises la méthode décrite par « Use pinning for installation ». Je te conseillais la méthode décrite par « Get packages upgraded from backports.debian.org », qui fais que tu modifies le fichier preferences une seule fois et pas à chaque paquet. Par contre il faut mettre le -t une seule fois, à l'installation du paquet.

  • # Attention

    Posté par  . Évalué à 6.

    Zenitram, du calme.
    Chut, douuuuucement, caaaaalme.

    :-)


    Si c'est officiel, il est peut-être envisageable que les paquets soient plus ou moins automatiquement rétroportés chaque fois qu'une version est mise en place pour sid.
    C'est idiot cette idée ?

    • [^] # Re: Attention

      Posté par  (site web personnel) . Évalué à 1.

      QUOI ?

      Bon, sérieusement, un rétroportage c'est pas mal e travail manuel.

      • [^] # Re: Attention

        Posté par  (site web personnel) . Évalué à 1.

        Et un paquet Debian aussi.

        • [^] # Re: Attention

          Posté par  . Évalué à 8.

          Si Manuel est le seul à faire les paquets et le rétro-portage, on comprend vite pourquoi ça prend du temps de sortie une nouvelle version stable...

          - - - - ---> [ ]

          • [^] # Re: Attention

            Posté par  (site web personnel) . Évalué à 3.

            Ben oui mais Intellectuel est déjà occupé


            Bon je te suis ------> [ ]

            Alexandre COLLIGNON

            • [^] # Re: Attention

              Posté par  . Évalué à 3.

              Il trolle sur debian-legal, forcément que ça n'avance pas !

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: Attention

      Posté par  (site web personnel) . Évalué à 3.

      Zenitram, du calme.
      Chut, douuuuucement, caaaaalme.

      Justement, oui, je suis calme : ça va dans le bon sens, celui de pouvoir choisir d'avoir certains logiciels plus à jour sans devoir tout casser. C'est une très bonne chose d'écouter les critiques, et d'adapter l'offre aux critiques (de manière officielle) plutôt que de faire l'autruche sur le problème. Il reste encore quelques défauts au système de paquets (des paquets pas à jour même dans SID ou des logiciels absents, des façons de faire différentes rpm vs deb qui empêche de mutualiser les efforts), mais le problème de devoir changer de version de noyau pour pouvoir profiter d'une version à jour d'un logiciel mineur a maintenant une réponse officielle de la part de Debian (modulo que le logiciel soit dans les backports). "Il n'y a pas de problème le système actuel est super-mégia-génial et parfait", n'empêche il a fallu changer quelque chose...

      Si c'est officiel, il est peut-être envisageable que les paquets soient plus ou moins automatiquement rétroportés chaque fois qu'une version est mise en place pour sid.
      C'est idiot cette idée ?

      Si j'ai bien compris, SID peut quand même tout casser (genre une API d'une lib), c'est pas un peu limite? Il me semble que c'est plus adapter des logiciels "mineurs" (qui ne cassent pas les libs) plus que pour tout ce que fait SID. Mais les experts pourront mieux répondre que moi.

      • [^] # Re: Attention

        Posté par  . Évalué à 3.

        C'était un clin d'oeil, je suppose que tu l'as reçu comme cela :-)

        Concernant la duplication des efforts, c'est justement cela qui me tracasse. Si on veut éviter cette duplication, il faut mettre en place un système complexe. Seules des personnes très au point pourront faire des paquets cross-distributions (ou même intra-distribution genre Lenny+Backport+sid).

        Or, le système actuel n'est déjà pas si simple. Dans mon cas par exemple, il est hyper facile pour moi de récupérer le source d'une version dans Sid et de la compiler dans Lenny (donc en profitant des patchs Debian qui sont généralement bien, en profitant des scripts init.d aux petits oignons, de la configuration logrotate, etc). Et pourtant je n'ai jamais créé un paquet Debian officiel.
        Paresse, pas envie de passer 3 jours à contacter la bonne personne, et d'autres mauvaises excuses. Je ne l'ai jamais fait alors que c'est _peut_être_ facile. C'est mauvais signe.

        Alors que j'ai l'impression qu'il est hyper simple d'automatiser la production de paquets vers backport. Un automate prend chaque paquet source de sid (ou d'unstable, ou les deux) et compile ça pour backport.
        On peut imaginer que les paquets qui ne compilent pas sont rejettés, il restera l'immense majorité. On met tout ça dans un dépôt séparé backport-auto histoire de bien comprendre que personne n'a vérifié, et ça roule.

        Ca risque de ne pas fonctionner pour les paquets complexes.
        Compiler à la mimine reste tout de même très simple.

        • [^] # Re: Attention

          Posté par  (site web personnel) . Évalué à 3.

          C'était un clin d'oeil, je suppose que tu l'as reçu comme cela :-)

          T'inquiette pas pour ça!

          Si on veut éviter cette duplication, il faut mettre en place un système complexe.

          Pas tant que ça : ce mettre d'accord sur une langue commune ne rend pas le système complexe. entre les script debian et les .spec, il y a redondance, et c'est une redondance inutile (je n'ai toujours rien vu qu'on peut faire d'un côté et pas dans l'autre). Juste que les gens ne veulent pas se mettre d'accord parce que "leur système est meilleur". Ensuite des règles de base commune (les répertoires, les noms des libs genre Qt), et pour ça il y avait LSB, mais comme le système de chacun est forcement meilleur, ça n'a pas été suivi non plus. Après, il y a des gens qui font bouger les choses, par exemple Canonical avec PPA (mais qui pense qu'à lui) ou Novell avec OBS (qui pense aux distribs "importantes", ça me sauve la vie, mais reste dépendant de la bataille deb vs rpm). Bref, non, ce n'est pas forcément un système complexe à mettre en place. Mais bon, ce n'est pas la où je voulais en venir en te répondant! Car le système des backport corrige en pratique un autre problème (celui des distribs figées qui sont super pour la stabilité mais dont on ne pouvait un logiciel à la con sans tout faire évoluer).

          Compiler à la mimine reste tout de même très simple.

          Pour un geek peut-être. Pas pour une personne normale.

        • [^] # Re: Attention

          Posté par  . Évalué à 0.

          En te lisant j’ai l’impression que tu décris tout simplement le apt-pinning. Si non quelles sont les différences avec ce que tu décris, parce que je n’en vois aucune ?

          Pour ce qui est l’unification des systèmes de paquets, il a été démontré dans un des trolls lancés par Zenitram que cela est impossible : ce n’est pas une question de formats mais de choix faits, la preuve : même deux distributions partageant le même format de paquets comme Debian ou Ubuntu n’assurent pas la compatibilité des paquets entre elles. Pour le cas qui nous occupe spécifiquement, n’importe quelle combinaison entre stable, testing et sid est incompatible de manière générale, apt-pinning marche jusqu’à un certain point, les backports sont là pour assurer la compatibilité qu’apt-pinning est incapable de fournir, avec comme prix à payer un choix plus limité. Cela tient aux choix de distribution : la modularité choisie, les dépendances obligent à avoir un tout cohérent, source ou binaire, système clef en main ou faut-il repasser par derrière pour configurer, etc.

    • [^] # Re: Attention

      Posté par  (site web personnel) . Évalué à 1.

      Vous voulez plus énorme ?

      http://cut.debian.net/

  • # "depuis au moins d'août"

    Posté par  . Évalué à 2.

    Va falloir choisir une formulation parce que ça ne veux rien dire quand on en mélange 2 ou 3.

    Sinon, c'est cool.

Suivre le flux des commentaires

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