Pourquoi les dépôts Ubuntu ne possèdent-ils pas les dernières versions du logiciel?

127

Pourquoi les paquets des dépôts officiels d'Ubuntu sont-ils plus anciens que les dernières versions (en amont) de Debian Sid, des PPA, des auteurs, etc.?

    
posée Thomas Ward 15.06.2012 - 16:20
la source

7 réponses

111

Une version d'Ubuntu passe par plusieurs étapes avant de devenir un produit fini:

  • Quelques temps avant qu'Ubuntu lance une version, il gèle ses paquets à un moment donné.

  • Avant la sortie d'une version mais après le gel du paquet, le travail est principalement effectué pour corriger tous les bogues et problèmes pouvant survenir dans ces paquets. Les nouvelles versions de package ne sont plus importées dans les référentiels après le gel du package ou des fonctionnalités.

  • Une fois la version terminée, des modifications supplémentaires à ces paquets ne sont apportées que pour la résolution des bogues et les problèmes de sécurité. Il n'y a plus de mises à jour apportées aux packages dans le référentiel officiel même si de nouvelles versions des packages sont publiées.

La nouvelle version des paquets est constamment importée (à partir de Debian) pour la prochaine version d'Ubuntu, jusqu'à ce que le prochain gel se produise et que le même processus se répète.

Par exemple, vous pouvez consulter le calendrier de publication du 12.04 .

Vous pouvez voir que même si 12.04 a été publié en avril, le 12 janvier, un élément appelé Gel d'importation Debian est arrivé.

Il s’agit de la première des nombreuses étapes de freeze qui ont lieu avant la version réelle et signifie que l’importation de paquets à partir des tests Debian ou instables s’arrête et que le travail commence à les personnaliser et à les résoudre.

Aucune mise à jour n'est effectuée après ce moment dans de nombreux paquets et la version de ce package à ce moment-là est la version présente et maintenue pendant toute la durée de vie d'une version.

Donc, même s'il existe des versions supérieures du même package dans les PPA des développeurs ou dans les référentiels Ubuntu + 1 ceux-ci ne seront inclus que dans la prochaine version d'Ubuntu.

Ceci est fait pour la stabilité, la sécurité et la fonctionnalité. Les nouveaux paquets perdus importés en permanence dans le référentiel principal impliqueraient des problèmes et d’autres problèmes à résoudre. Un gel dans la version des paquets permet de trier et de rendre Ubuntu plus sûr et plus stable pour l'utilisateur final.

Une nouvelle version d'Ubuntu est publiée tous les 6 mois. Tous les 6 mois, de nouveaux paquets sont préparés, testés, personnalisés et publiés avec une nouvelle version. Les futures versions d'un package peuvent être installées sur votre système via un PPA ou simplement en le téléchargeant depuis un site Web, mais la version du package dans le référentiel officiel reste la même.

Jetez un coup d’œil à ReleaseSchedule - LTS à LTS et page Stable Release Updates pour une présentation et une explication complètes d'une version stable d'Ubuntu.

    
réponse donnée Bruno Pereira 15.06.2012 - 17:01
la source
14

Deux raisons. La première est tout à fait évidente: il faut que l’homme passe du temps à mettre à jour le paquet lorsqu’un nouveau flux amont est lancé. La seconde est que si vous exécutez une version stable par opposition à la version de développement actuelle, les packages ne sont intentionnellement pas mis à jour régulièrement pour éviter les ruptures. Voir lien .

    
réponse donnée psusi 15.06.2012 - 16:27
la source
12

Les packages sont gelés pour la version et ne sont pas mis à jour par la suite pour plusieurs raisons. Si de nouvelles versions étaient introduites après la publication, alors la nouvelle version ...

  • pourrait apporter de nouveaux bogues, ce qui ferait régresser les fonctionnalités présentes au moment de la publication
  • a besoin de main-d'œuvre pour emballer, tester et télécharger
  • a besoin de son propre ensemble de mises à jour de sécurité
  • aurait besoin de traductions mises à jour pour son interface utilisateur
  • aurait besoin d’une documentation à jour (et de traductions)
  • rend le support technique plus difficile
  • peut ennuyer les utilisateurs qui se sont habitués aux fonctionnalités de l’ancienne version
  • peut nécessiter des dépendances plus récentes qui pourraient casser d'autres applications si elles étaient modifiées dans le référentiel
  • peut casser d'autres paquets qui dépendent de celui-ci
  • peut casser les scripts d’utilisateur, les modèles, les outils, etc. créés pour l’ancienne version

Cela dit, sachez qu’il ya des cas où Ubuntu fait des mises à jour complètes des versions de logiciels dans le référentiel. Firefox par exemple.

En outre, il existe un référentiel ubuntu-backports sur lequel les utilisateurs peuvent opter pour mettre à jour les progiciels qui ne causeront pas de problèmes tels que ceux répertoriés ci-dessus. Il n'est pas activé par défaut pour que les utilisateurs puissent y adhérer, ce qui est fait pour éliminer la surprise de voir votre logiciel changer sous vos yeux. De plus, il n’a pas beaucoup de personnel et je ne suis donc pas sûr de la fréquence à laquelle les paquets reçoivent les mises à jour.

En outre, l’équipe SRU a récemment mis à jour des stratégies qui, espérons-le, faciliteront la mise à jour des mises à jour de paquets uniquement.

    
réponse donnée Bryce 20.06.2012 - 10:32
la source
11

Normalement, les mises à jour des versions d’Ubuntu sont destinées à la sécurité et aux corrections de bogues, par exemple:

  • Bogues pouvant, dans des circonstances réalistes, provoquer directement une vulnérabilité de sécurité. Celles-ci sont effectuées par l'équipe de sécurité et sont documentées sur SecurityTeam / UpdateProcedures.

  • Bogues représentant des régressions sévères de la version précédente d'Ubuntu. Cela inclut les paquets totalement inutilisables, comme la désinstallation ou le blocage au démarrage.

  • Bogues pouvant, dans des circonstances réalistes, provoquer directement une perte de données utilisateur Les bogues qui ne rentrent pas dans les catégories ci-dessus, mais (1) ont un correctif évidemment sûr et (2) affectent une application plutôt que les packages d'infrastructure critique (comme X.org ou le noyau).

  • Pour les versions de support à long terme, nous souhaitons régulièrement activer un nouveau matériel. Ces modifications sont appropriées à condition que nous puissions nous assurer de ne pas affecter les mises à niveau sur le matériel existant. Par exemple, les modaliases des pilotes nouvellement introduits ne doivent pas chevaucher les pilotes livrés précédemment. -Nouvelles versions du logiciel commercial dans l'archive partenaire de Canonical.

    -FTBFS (Échec de la construction à partir de la source) peut également être pris en compte. Veuillez noter que dans la version principale, le processus de publication garantit qu'aucun fichier binaire n'est généré à partir d'une source actuelle. Habituellement, ces bogues ne doivent être utilisés qu'avec une autre correction de bogue.

    -Pour les nouvelles versions en amont des paquets qui fournissent de nouvelles fonctionnalités, mais ne corrigent pas les bogues critiques, un backport devrait être demandé à la place.

Tiré de l’excellente page wiki StableReleaseUpdates .

    
réponse donnée pl1nk 13.06.2012 - 19:38
la source
11

Je vais essayer de répondre à vos questions sur la base de mes expériences passées de forums Ubuntu et de Ubuntu Planet.

Je suppose que je me demande comment les référentiels apt sont mis à jour, et par qui.

Les repos APT sont mis à jour par l’équipe d’emballage d’Ubuntu. L'équipe de conditionnement obtient tous les paquets en amont des développeurs qui effectuent un premier test d'emballage et d'autres choses. Ensuite, l'équipe de test effectue le test final en donnant un signal de départ. Mais l’équipe de conditionnement et les équipes de test sont très prudentes quant aux dépendances et leurs effets secondaires sur le système stable.

En cas de décalage, est-ce parce que le développeur n'a pas poussé la version la plus récente sur le serveur concerné?

Si vous constatez les modifications en amont, des milliers de développeurs souhaitent pousser leurs packages. Mais tous ne sont pas entrés dans le flux principal, car pour diverses raisons. Supposons que l'application Gedit, une version 2.2 soit adaptée et fonctionne bien avec Dbus 2.1 et Gtk 2.4, etc. Où la version de Gedit 2.4 (toute nouvelle) nécessite Gtk 2.5 et Dbus2.3 pour fonctionner. Désormais, l'équipe chargée des tests et de l'emballage (également l'équipe de publication) ne l'accepte pas, car changer un système existant ayant un ancien dbus et un nouveau gtk avec le nouveau système brise tout le reste. J'espère que vous avez le point de l'enfer de la dépendance.

Le développeur a-t-il encore beaucoup à faire pour obtenir la version sous une forme utilisable par le référentiel?

Pas pour le canal en amont. Mais pour le canal de publication oui :).

P.S: Il pourrait y avoir quelques modifications apportées au processus maintenant dans le canonique par rapport à ce qui est expliqué ci-dessus. Mais c'est plus ou moins la même chose.

    
réponse donnée Zenwalker 13.06.2012 - 19:46
la source
6

La réponse acceptée dans le lien fossfreedom publié en tant que commentaire est très bonne.

En général, les versions de package publiées après la première partie du processus de développement de la nouvelle version n'apparaissent pas dans les référentiels principaux de cette version, ce qui permet de tester à fond une version Ubuntu fiable.

Vous constaterez peut-être que certains paquets sont publiés dans le référentiel de backports s'ils sont intégrés avec succès dans une future version d'Ubuntu et si les développeurs pensent qu'ils fonctionneront également avec les versions antérieures. Les backports peuvent être activés et désactivés dans le Software Center (Edit- & gt; sources de logiciels- & gt; onglet Updates- & gt; mises à jour non prises en charge)

    
réponse donnée John S Gruber 30.06.2012 - 00:58
la source
-3

La réponse n'est pas complète.

Certains logiciels sont disponibles dans une version backport de Software Center. Dans la partie droite de la fenêtre, juste à gauche du bouton Installer / Modifier, il y a une zone de sélection où vous pouvez modifier la version.

Exempli gratia: conky par défaut est maintenant 1.8.x et vous avez 1.9.0 (precise-backports) comme backport. Bien entendu, les backports doivent d'abord être activés.

Source: lien

EDIT: Comme indiqué ci-dessous, tous les packages ne disposent pas de backport, mais vous pouvez parfois y accéder rapidement si vous êtes assez chanceux.

    
réponse donnée Benjamin 27.06.2012 - 01:48
la source

Lire d'autres questions sur les étiquettes