Linux? - Page 264

L U L

Quand un Kevin Kofler-like s'occupe de maintenir un paquet pour sa distro et que son opinion importe plus que les features demandées par les utilisateurs et que l'équipe de développement de l'application concernée :

Si on fouille dans les sources originales linkées dans la description de la vidéo (que je n'ai pas regardée car je préférais regarder les sources pour me faire ma propre opinion), on trouve des sub-threads comme https://fosstodon.org/@nik@toot.teckids.org/112421864158175357 , où le mainteneur de package répond, et indique un plan possible (si le renommage a lieu) pour une transition entre la version réduite et la version complète qui a un maximum de features et donc certainement une surface d'attaque plus grande, ou encore d'autres sub-threads qui mentionnent que vim et nginx, par exemple, sont déjà packagés en une version basique et une version complète. Transition qui aura lieu longtemps avant que la prochaine version de la distro, dans plus d'un an, soit publiée.

Le mainteneur downstream aurait probablement pu mieux gérer cette situation en faisant ce split plus tôt, mais la situation semble un peu plus compliquée que ce que tu décris ?

Alors j'ai peut-être aussi un point de vue incomplet mais j'avais lu le drama sur Github il y'a quelques jours (lien) et c'est difficile d'éprouver de la sympathie pour le packageur

Mouais. En effet, sur la forme, c'est très mal dit, et je comprends bien pourquoi ça fait penser à une certaine personne
Sur le fond, il n'a pas tout faux - plus de features auxiliaires = plus de surface d'attaque, et que plein de choses aient été compilées par défaut (et que ce ne soit pas des plugins packageables séparément) est un problème.

Quelques posts plus bas, on trouve à la fois un ancien mainteneur de KeepassXC qui indique qu'il est d'accord avec le packager Debian, un mainteneur actuel de KeepassXC qui dit qu'il n'a pas de problème avec le package minimal mais que c'est à upstream que ce changement de comportement du package par défaut va bouffer du temps (il a raison)... et un mainteneur actuel qui dit que puisque c'est comme ça, ils vont réduire le nombre de parties du code qu'on peut sélectionner ( ) et que c'est la version des mainteneurs avec plein de choses qui est la plus sûre, ce qui est clairement faux, comme le lui répond l'ancien mainteneur .

Bref. Blame on both sides, mais j'espère que d'autres distros qui ne l'auraient pas encore fait vont suivre ce changement du package Debian, en s'y prenant mieux pour la transition.

À chaque fois que je lis ce genre de débats, je suis bien content de ne rien avoir développé qui soit packagé par des distribs Linux. Faut vraiment être courageux pour se taper le support de plein de versions bricolées, par des personnes différentes, sur lesquelles on n'a aucun contrôle.

idem, c'est pour ça que je ne partage pas mes sources

Lordkraken m'en est témoin "mais pourquoi t'as mis deux elseif là, un switch aurait été plus performant" et en fait "ptet parce que j'ai du écrire ce code tard dans la nuit ;D"

(mais bon, l'honneur est sauf, je lui ai montré après ce qu'il considérait comme une bidouille et qui en fait permet d'augmenter réellement les fps pour la gestion du double buffer )

Bon après de juger un code c'est pas forcément dans une démarche destructive, ça aide à s'améliorer. Mais comme tous ces jugement c'est à l'auteur de choisir ce qu'il en fait.

./7896: comme dans ce cas, le débat a pris des proportions élevées, l'information s'est répandue. Mais dans la grande majorité des cas, l'interaction entre upstream et les packagers downstream - quand elle a lieu, parce qu'il y a certainement plein de cas où il n'y en a simplement pas besoin - se passe bien. Je doute que les distros Linux parviendraient à un tel nombre de packages - des milliers de packages source produisant jusqu'à quelques dizaines de milliers de packages binaires - et survivraient 20+ ans si les gros problèmes étaient un tant soit peu fréquents

Le bricolage des versions par downstream existe, bien sûr, et ce au-delà des backports de sécurité sur des versions non maintenues upstream. Cependant, si downstream et upstream font correctement leur boulot (signalement de bugs et patches utiles par downstream, intégration par upstream, ouverture d'esprit d'upstream à des améliorations qui ont du sens...) en bonne intelligence, à mon sens, la quantité de bricolage downstream reste minime - et dans ce cas, le problème de support de versions bricolées n'existe pas.

Je maintiens quelques logiciels packagés par des distributions Linux. Les packagers de libti*gfm/tilp/tiemu sont polis, et me remontent des améliorations qui ont du sens pour upstream et pour les autres distros: j'ai donc tendance à les intégrer, pour améliorer les choses pour tout le monde. J'ai moins eu l'occasion d'interagir avec des downstreams de memtest86+, certainement bien plus largement utilisé que des logiciels pour calculatrices graphiques TI, et depuis moins longtemps; cependant, par exemple, les packagers Debian ont été un peu présents autour de l'intégration de la nouvelle génération de memtest86+ à Debian.

Intéressant