No One Can Agree Who Is Responsible For Linux
Cette vidéo explore les tensions récurrentes entre les développeurs en amont (upstream) et les mainteneurs de paquets en aval (downstream) dans l’écosystème Linux, illustrées par des conflits concrets autour de versions obsolètes, de paquets non officiels et de diverg...
SYNTHÈSE STRUCTURÉE
Le modèle de distribution Linux est unique
Contrairement aux logiciels propriétaires où le développeur et le distributeur sont souvent les mêmes, dans le monde du libre, les paquets sont généralement empaquetés par des tiers. Comme le dit l’intervenant : « the Fedora packaging, the Debian packaging, the OpenSUSE packaging, the Arch packaging, the Gentoo packaging, all of this other packaging, and even done multiple times in a singular family line, are done by entirely different people with oftentimes entirely different motivations and expectations ». Cette séparation crée un terrain fertile pour les incompréhensions.
Conflit Gnome Calendar vs Linux Mint
Les développeurs de Gnome Calendar ont demandé à Linux Mint de supprimer les liens vers leur projet et le branding, car Mint livrait une version très ancienne (issue d’Ubuntu LTS). Les signalements de bugs remontaient pourtant aux développeurs upstream. Mint a répondu en renvoyant la responsabilité vers Ubuntu, puis son fondateur Clem a déclaré : « we can ship whatever version we want, if you don’t like that, change the license ». L’intervenant souligne que « Mint’s counter-argument was, why are you bothering us? We’re just shipping what Ubuntu LTS provides ».
Bug KDE Plasma sur Debian
Un utilisateur a signalé un bug de Bluetooth sur KDE Plasma 6.3.6, une version très ancienne. Les développeurs KDE ont refusé de traiter le ticket, indiquant que « this bug has probably already been fixed in a modern version » et ont redirigé l’utilisateur vers Debian. L’intervenant précise : « this reporter was pretty much just demanding, hey, this is KDE software, fix the KDE software, why is the software broken? ».
Problèmes avec les paquets Fedora (Bottles et OBS)
Deux cas illustrent la confusion des utilisateurs :
- Bottles : le RPM Fedora était cassé et non supporté par l’équipe Bottles, donnant une mauvaise image du logiciel.
- OBS Studio : le Flatpak Fedora masquait FlatHub, poussant les utilisateurs à télécharger une version inférieure sans le savoir. L’intervenant explique : « Fedora Flatpak was effectively masking FlatHub, where if you had it enabled, it wasn’t really obvious where the Flatpak was coming from ». Les rapports de bugs allaient alors à l’équipe OBS pour un paquet qu’elle ne gérait pas.
Les attentes divergentes entre upstream et downstream
Les développeurs upstream connaissent parfaitement leur logiciel, mais pas les spécificités de chaque distribution. Les mainteneurs downstream maîtrisent leur système de paquets (RPM, DEB, etc.) et les besoins de leurs utilisateurs. L’intervenant résume : « upstream and downstream often have very different expectations for what the package should look like, how it should be packaged, the acceptable level of packaging, the way that bugs should be handled ».
L’argument de la sécurité : l’affaire XZUtils
L’intervenant note que la fragmentation des paquets a joué un rôle positif dans l’affaire XZUtils : « What played a large part in stopping that being a major backdoor […] is that there wasn’t just a single package that everybody installed, that everybody updated to ». Les distributions n’avaient pas encore intégré la version compromise, limitant l’impact.
Le cas des LTS et l’exemple Pop!_OS
Les distributions LTS (Long Term Support) créent une confusion chez les utilisateurs. Pop!_OS 24.04 LTS, par exemple, est présentée comme stable mais intègre des composants roulants (rolling). L’intervenant critique : « LTS to a lot of people implies stability. […] But at the same time with Pop! OS, parts of the system are rolling ». Cela génère un décalage entre l’étiquette et l’expérience réelle.
Recommandation pour le signalement de bugs
L’intervenant donne une règle claire : si vous utilisez un paquet officiel (ex. Flatpak OBS), signalez le bug directement aux développeurs. Sinon, passez d’abord par le bug tracker de votre distribution : « if it is not a bug on the distro, then they can direct you up to upstream ». Cela évite de noyer les développeurs avec des problèmes liés à l’empaquetage.
CONCEPTS CLÉS
- Upstream : développeurs originaux d’un logiciel (ex. l’équipe Gnome Calendar).
- Downstream : mainteneurs qui empaquettent et distribuent le logiciel pour une distribution spécifique (ex. les packagers Debian ou Fedora).
- LTS (Long Term Support) : version d’une distribution bénéficiant de mises à jour de sécurité et de correctifs sur plusieurs années, mais souvent avec des logiciels figés.
- Flatpak / AppImage / Snap : formats d’empaquetage universels qui permettent aux développeurs upstream de distribuer directement leur logiciel, indépendamment de la distribution.
CONCLUSION
Le message principal est que la séparation upstream/downstream est une force de l’écosystème Linux (diversité, sécurité), mais qu’elle exige une communication claire et une gestion rigoureuse des attentes. L’intervenant conclut : « if you’re engaging in it, you do need to keep in mind that you’re probably approaching this from a very different perspective ». Pour un administrateur, cela signifie qu’il faut toujours vérifier la source d’un paquet, privilégier les formats officiels upstream quand c’est possible, et orienter les signalements de bugs vers le bon canal (distribution ou développeur).