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.