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 dernières versions (en 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) dans 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, en janvier 12, quelque chose a appelé blocage de l’importation Debian est arrivé.
Il ne s’agit que de la première des nombreuses étapes de gel précédant la publication effective. Cela signifie qu’à ce stade, l’importation de paquets provenant de Debian testing ou unstable s’arrête et s’efforce de les personnaliser et de 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 maintenue 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 tout le temps 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 6 mois. Ainsi, tous les 6 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 œil à ReleaseSchedule - LTS à LTS et page Mises à jour de versions stables pour une version complète. aperçu et explication d'une 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 la fonctionnalité qui était présente 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
Cela dit, sachez qu'il existe des cas où Ubuntu fait effectue des mises à jour complètes des versions logicielles dans le référentiel. Firefox par exemple.
De plus, 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, ce qui oblige les utilisateurs à y adhérer, ce qui a pour but d'éviter la surprise de voir votre logiciel se modifier. 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.
En outre, l’équipe SRU a récemment mis à jour un peu les stratégies, ce qui facilitera l’obtention 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 planter au démarrage.
Bugs qui, dans des circonstances réalistes, peuvent directement causer 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 d'apt sont mis à jour et par qui.
Les dépôts APT sont mis à jour par l'équipe de packaging 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 d’emballage et les équipes de test sont très prudentes vis-à-vis des dépendances et leurs conséquences sur le système stable.
Quand il y a un décalage, 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 le changement d'un système existant doté de l'ancien dbus et de gtk avec le nouveau casse le reste. J'espère que vous avez la dépendance de l'enfer.
Le développeur a-t-il encore beaucoup à faire pour obtenir la version dans un formulaire pouvant être utilisé par le référentiel?
Pas vers le canal en amont. Mais pour le canal de sortie oui :).
P.S: Il pourrait y avoir un peu de changements apportés au processus dans le canonique par rapport à ce qui est 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 constaterez peut-être que certains packages sont publiés dans le référentiel backports s'ils sont intégrés avec succès dans une version ultérieure 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).