• [^] # Re: Mouaif

    Posté par . En réponse au journal Pourquoi écrire un package Debian est-il si compliqué?. Évalué à 1. Dernière modification le 09 septembre 2014 à 10:27.

    EDIT : grillé.

    Maintenant, je soupçonne que cela permette moins choses en contrepartie, comme l'indication formelle des licences utilisées

    https://guide.macports.org/#development.examples

    license GPL

    On parle d'essence ?

    l'ajout de patchs spécifiques annotés

    Ce n'est pas à ça que sert le changelog du projet ?

    Ah non excusez-moi, on parle de mainteneurs qui ont patché des logiciels à l'insu des développeurs. Il faut forcément avoir un changelog spécifique aux bidouilles Debian.

    le suivi des versions du logiciel amont et des révisions de l'empaquetage

    Même lien :

    version 1.2.23

    Et bien !

    les notifications automatiques de la présence d'une nouvelle version amont avec automatisation du téléchargement et de leur intégration dans ton empaquetage

    Gné ? Que le serveur dise "j'ai la version 1.2.23" et que le client comprenne "tiens, j'ai la 1.2.21 sur mon ordi, il y a donc une nouvelle version" quand le client met à jour la liste des paquets des dépôts, ça nécessite de complexifier la procédure de création de paquet ?

    la définition éventuelle des fichiers à mettre dans tel ou tel paquet binaire dans le cas d'une séparation en plusieurs paquets.

    Là, je suis curieux d'avoir des cas pratiques. De ce que je comprends, le développeur doit dire comment il faut scinder son projet pour que les mainteneurs puissent changer 1 gros package en plusieurs petits. Plutôt que d'ajouter de la complexité à un format pour un problème humain (le développeur a préféré tout foutre ensemble au lieu de créer un paquet principal + un paquet lib), on pourrait simplement... dire par mail ou même dans la doc "écoute, on voit que ton dossier lib a l'air épais, tu devrais le séparer dans son propre paquet, vu que ton code est libre ça pourra profiter aux autres" pour le développeur qui fait son paquet.

    Alors certes, il y a une raison d'être, mais ces raisons d'être sont-elles encore pertinentes ? Un gros nettoyage pourrait être fait, mais quand on parle de fonctionnalités, on adore tout garder, même quand on parle de simplifier le code.

    Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/