• [^] # Re: Euh, oui, mais non

    Posté par (site web personnel, Mastodon) . En réponse au lien 2022 was the year of Linux on the Desktop. Évalué à 5.

    Aucune différence avec chocolatey donc, ou tu mets ta confiance dans :

    Si justement, avec Chocolatey il y a en plus la confiance dans le binaire généré par l'upstream.

    Et l'exemple de VS Code montre justement que c'est un problème: l'upstream crée uniquement des binaires privateurs qui ajoutent des outils indésirables sur un logiciel pourtant opensource.

    Chocolatey n'a aucune maitrise sur les binaires produits par Microsoft.

    Alors que Debian, avec sa charte signée par tous les mainteneurs, ne fournira que ce qui est disponible en opensource. C'est pourquoi ils doivent compiler eux-mêmes les binaires pour VS Code.

    Pire, tu as AUR (archlinux), npm, PyPI, crates.io, etc... qui ne sont pas curated par des mainteneurs.

    De plus, combien de fois je dois ajouter un dépôt au sources.list (vscode, mongodb, node, ...), l'argument tiens encore moins.

    C'est pour cette raison que je ne parlais uniquement des dépôts Debian et de ce que fournis Debian de base.

    S'il manque des logiciels dans Debian, il est possible de les ajouter en respectant la charte et en participant à la communauté Debian.

    Impossible avec Chocolatey vu qu'il semble qu'il n'y a aucune infrastructure pour construire et héberger les binaires.

    Qu'est-ce qui dans l'architecture de chocolatey empêche la création d'un paquet vscodium ?

    C'est un index de liens, il n'y a pas de code source hebergé et de binaires générés par Chocolatey.

    Cela existe déjà en plus : https://community.chocolatey.org/packages/vscodium

    Mais c'est le projet vscodium qui fourni les binaires et non pas Chocolatey, n'est-ce pas ? Si oui, le problème est toujours là.