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

Pourquoi les paquets dans les dépôts officiels Ubuntu sont-ils plus anciens que les versions les plus récentes (amont) de Debian Sid, les PPA, les auteurs, etc.?

Une version Ubuntu franchit plusieurs étapes avant d’être rendue publique comme produit fini:

• Quelque temps avant que Ubuntu ne publie une version, ses paquets sont gelés à un moment donné.

• Avant la publication d'une version, mais après la congélation du paquet, le travail consiste principalement à résoudre tous les bogues et problèmes susceptibles de se produire dans ces paquets. Les nouvelles versions de packages ne sont plus importées dans les référentiels après le gel des packages ou des fonctionnalités.

• Une fois la publication effectuée, les modifications supplémentaires apportées à ces packages ne concernent que la résolution des bogues et les problèmes de sécurité. Aucune mise à niveau n'est effectuée pour les packages dans le référentiel officiel, même si de nouvelles versions des packages sont publiées.

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

À titre d'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 blocage appelé Debian Import Freeze s’est produit.

Il ne s’agit que de la première des nombreuses étapes de gel ayant lieu avant la publication effective. Cela signifie qu’à ce stade, l’importation de paquets à partir des tests Debian ou des arrêts instables est un travail qui commence pour les personnaliser et les résoudre.

Aucune mise à niveau n'est effectuée après ce point dans un grand nombre de packages et la version de ce dernier est la version présente et conservée pendant toute la durée de vie d'une version.

Ainsi, 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, celles-ci ne seront incluses que dans la prochaine version d'Ubuntu.

Ceci est fait pour la stabilité, la sécurité et la fonctionnalité. De nouveaux paquets de saignement importés en permanence dans le référentiel principal signifient des problèmes et beaucoup plus de problèmes à résoudre. Un gel de la version des packages permet de résoudre ce problème et de rendre Ubuntu plus sûr et plus stable pour l'utilisateur final.

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

Pour plus de compréhension et un aperçu intéressant de ce qui est arrivé à Ubuntu du 10.04 au 12.04, jetez un coup d’œil à la page ReleaseSchedule - LTS à LTS et Mises à jour des versions stables pour une présentation complète et une explication de la version stable d’Ubuntu.

Deux raisons. La première est assez évidente: il faut un humain pour passer du temps à mettre à jour le paquet quand un nouveau fichier en amont sort. 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 volontairement pour éviter les ruptures. Voir http://wiki.ubuntu.com/StableReleaseUpdates .

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

• pourrait apporter de nouveaux bogues, régressant ainsi 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 ses propres mises à jour de sécurité
• aurait besoin de traductions mises à jour pour son interface utilisateur
• aurait besoin de documentation mise à jour (et de traductions)
• rend le support technique plus difficile
• peut gêner les utilisateurs habitués aux fonctionnalités de l'ancienne version
• peut nécessiter de nouvelles dépendances qui pourraient endommager 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 utilisateur, modèles, outils, etc. créés pour l'ancienne version

Tout cela étant dit, sachez qu'il ya des cas où Ubuntu exerce ses pas mises à jour complètes des versions logicielles dans le référentiel. Firefox par exemple.

En outre, il existe un référentiel ubuntu-backports qui permet aux utilisateurs de choisir les mises à jour de progiciels ne causant pas les problèmes énumérés ci-dessus. Il n'est pas activé par défaut, de sorte que les utilisateurs doivent y adhérer, ce qui a pour but d'éliminer la surprise de voir votre logiciel passer de sous vous. De plus, il n’ya pas beaucoup de personnel et je ne suis donc pas sûr de la fréquence à laquelle les paquets reçoivent des mises à jour.

De plus, l’équipe SRU a récemment mis à jour un peu les politiques, ce qui, espérons-le, rendra un peu plus simple l’installation de mises à jour de paquetages ne contenant que des correctifs.

Normalement, les mises à jour dans les versions publiées d'Ubuntu concernent la sécurité et les corrections de bogues. Voici des exemples de ces bogues:

• Bugs qui, dans des circonstances réalistes, peuvent directement causer une faille de sécurité. Celles-ci sont effectuées par l'équipe de sécurité et sont documentées dans SecurityTeam / UpdateProcedures.

• Bugs qui représentent des régressions graves de la version précédente d'Ubuntu. Cela inclut les packages qui sont totalement inutilisables, comme être désinstallé ou en panne au démarrage.

• Bugs qui peuvent, dans des circonstances réalistes, entraîner directement une perte de données utilisateur Bugs qui ne rentrent pas dans les catégories ci-dessus, mais (1) ont un patch évidemment sûr et (2) affectent une application plutôt que des packages d'infrastructure critiques (comme X.org ou le noyau).

• Pour les versions de support à long terme, nous souhaitons régulièrement activer de nouveaux matériels. Ces modifications sont appropriées à condition que nous puissions nous assurer que les mises à niveau sur le matériel existant ne sont pas affectées. Par exemple, les modalias des pilotes nouvellement introduits ne doivent pas faire double emploi avec les pilotes précédemment livrés. -Nouvelles versions de logiciels commerciaux dans les archives des partenaires Canonical.

  -FTBFS (Échec de la construction à partir de la source) peut également être considéré. Veuillez noter que, dans le processus principal, le processus de publication permet de s’assurer qu’aucun fichier binaire n’est construit à partir d’une source actuelle. Généralement, ces bogues ne doivent être SRU que conjointement à un autre correctif.

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

Tiré de l'excellente page wiki StableReleaseUpdates .

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

Je suppose que je me demande simplement comment les dépôts apt sont mis à jour et par qui.

Les dépôts APT sont mis à jour par l’équipe de conditionnement d’Ubuntu. L’équipe d’emballage reçoit tous les paquets en amont des développeurs qui effectuent les tests initiaux d’emballage, etc. Ensuite, l’équipe de test effectue les derniers tests en donnant le signal de départ. Mais l'équipe de conditionnement et les équipes de test sont très prudentes vis-à-vis des dépendances et leurs conséquences sur le système stable.

Est-ce parce que le développeur n'a pas envoyé la version la plus récente sur le serveur approprié?

Si vous voyez les modifications en amont, des milliers de développeurs souhaitent pousser leurs packages. Mais tous ne sont pas réussis dans le flux principal, c'est parce que pour diverses raisons. Supposons que l’application Gedit, une version 2.2 convienne et fonctionne bien avec Dbus 2.1 et Gtk 2.4, etc. Là où la version Gedit 2.4 (toute nouvelle) nécessite Gtk 2.5 et Dbus2.3 pour fonctionner. Maintenant, l'équipe de test et de packaging (l'équipe de publication) n'accepte pas cela, car la modification d'un système existant doté de l'ancien dbus et de gtk par le nouveau casse à tout le monde. J'espère que vous avez la dépendance de l'enfer.

Le développeur a-t-il encore beaucoup de travail à faire pour publier la version sous une forme que le référentiel peut utiliser?

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

PS: Il pourrait y avoir un peu de modifications apportées au processus dans le canonique par rapport à ce qui a été expliqué ci-dessus. Mais c'est plus ou moins pareil.

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

En général, les versions de paquet publiées après la première partie du processus de développement d'une nouvelle version n'apparaissent pas dans les référentiels principaux de cette version, de sorte qu'une version fiable d'Ubuntu peut être testée de manière approfondie.

Vous pouvez constater que certains packages sont publiés dans le référentiel backports s'ils sont intégrés avec succès dans une future version d'Ubuntu et si les développeurs pensent que cela fonctionnera également avec les versions précédentes. Les backports peuvent être activés et désactivés dans le Centre logiciel (Édition-> Sources logicielles-> onglet Mises à jour-> Mises à jour non prises en charge).

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

Certains sont packagés, qui peuvent être installés dans une version de backport à partir du centre logiciel. Dans la partie droite de la fenêtre, à gauche du bouton Installer / Modifier, vous trouverez une zone de sélection dans laquelle vous pouvez modifier la version.

Exemple de gratia: La valeur par défaut conkyest maintenant 1.8.xet vous avez là-bas en 1.9.0 (precise-backports)tant que backport. Bien sûr, les backports doivent être d'abord activés.

Source: http://bugs.launchpad.net/ubuntu/+source/conky/+bug/1003727

EDIT: Comme indiqué ci-dessous, tous les packages n’ont pas un backport, mais vous pouvez avoir un accès anticipé parfois si vous êtes assez chanceux.