Re: debian/ et upstream
On Mon, Sep 08, 2003 at 07:42:07AM +0200, Georges Mariano wrote: On Mon, 8 Sep 2003 07:48:00 +0200 Jeremie Koenig [EMAIL PROTECTED] wrote: Je souhaiterais mettre le repertoire debian/ dans l'upstream tarball Mauvaise idée. C'est un truc que j'arrive pas à comprendre ... Par exemple, dans le cas où je développe _et_ empaquête une appli, je dois séparer les deux ? Il y a là une discontinuité de comportement (entre upstream et DD) que j'arrive pas à motiver... C'est effectivement ce que conseille la reference des developpeurs (il me semble). C'est pas bien de polluer les tarballs. Ca embete les autres distribs et ca sert a rien. En plus, si jamais tu as moins de temps libre, et decide de lacher le developpement a la source et/ou celui debian, avoir separe les taches du debut peut aider tes remplacants. Par ailleurs, on peut pas dire d'un côté que le DD et upstream doivent communiquer étroitement [évidence] et considérer de l'autre que le debian/ dans CVS (la meilleure preuve donc!) soit une mauvaise idée ... Et, oh, on parle de quoi, la exactement ? Mettre le debian/ dans les tarball upstream est une erreur, mais je trouve personellement que c'est une bonne idee de mettre debian/ dans le *CVS* du projet upstream... Par exemple, j'ai repris la maintenance d'un ptit jeu qui se trouve etre dans debian, et j'ai propose au DD de nous rejoindre sur savannah afin qu'il place son debian/ dans le meme CVS que nous, et qu'il se sente membre du projet a la source aussi, mais ca ne s'est pas (encore) fait. C'est un peu bete je trouve. Il n'etait pas question pour moi de mettre debian/ dans les tarballs publiees, pas plus que les spec, mais plutot d'ouvrir le CVS upstream au DD, histoire qu'il corrige directement les bugs a la source au lieu de maintenir des piles de patchs a la con. C'est ce que je fais pour un autre programme, ou je suis ce coup ci principalement empaqueteur et un tout petit peu devel (j'ai juste fait l'i18n du truc). Le debian/ est gere dans le meme CVS que le source upstream. Le développement upstream et debian sont deux choses distincte, et il faut pouvoire sortir des révisions de paquets plus souvent, sans sortir une nouvelle version upstream, Je comprends pas pourquoi l'un empêcherait l'autre ... ?? cvs me semble suffisamment souple pour préserver la distinction des deux choses ...? Ce qui est un peu galere, c'est que si tu veux decouper (ie, ne pas faire un paquet natif, ce qui serait mal si ce n'est pas seulement destine a Debian), il faut que tu ait une archive orig.tar.gz pour que dpkg-buildpackage trouve contre quoi faire le diff.gz Et c'est super piegeux de ne pas se melanger les pinceaux, et de bien refaire ton orig.tar.gz quand tu corrige un bug dans le source, monter le numero de version, ajouter une entree dans le changelog debian New upstream release, faire to orig.tgz, le deplacer d'un etage plus haut en le renomant, et enfin lancer dpkg-buildpackage sudo dpkg -i ../*.deb puis tester... Enfin, s'il est vrai que cela doit être découragé pourquoi avoir mis le debian/ _dans_ les sources ? On peut très bien imaginer de sortir le debian/ non ? (d'ailleurs est-ce possible ?) Ce n'est pas decourage du tout, et d'ailleurs, si tu cherche un exemple de programme upstream ayant le debian/ dans le meme CVS, t'as pas besoin de chercher bien loin : dpkg est maintenu de la sorte ;) Bye, Mt. -- It worries me however, to realize how tough an ass-hole I have had to be, in order to get to stick to the principle of doing things right, rather than just hack it in. --- Poul-Henning Kamp [EMAIL PROTECTED]
Re: debian/ et upstream
Bonjour On Monday 08 September 2003 09:57, Georges Mariano wrote: On Mon, 8 Sep 2003 09:57:40 +0200 Xavier Roche [EMAIL PROTECTED] wrote: Autre argument: votre application n'est pas specifique a Debian, donc mettre le repertoire debian/ ne va pas aider les empaqueteurs d'autres distributions (mandrake, etc.) ça va pas les déranger non plus! cf les .spec pour rpm qui sont maintenant dans beaucoup de sources. Et qui sont inutiles, car souvent prévus pour une autre distribution et donc ne respectant pas les conventions et les macros mises en places. Sans compter que je doute fortement de la qualité d'un rpm fait par un développeur qui n'a pas l'habitude et qui fait souvent ça comme un goret. Jusqu'à preuve du contraire, les méthodes d'empaquetage sont indépendantes, elles peuvent donc cohabiter dans les mêmes sources ... (au passage : ça facilite bien la tâche d'un utilisateur rpm qui reçoit ces sources alors pourquoi pas aider l'utilisateur debian ?) Ça ne facilite que dalle. En général, il y a un .spec, qui correspond a RH quand on est chanceux et a rien dans la plupart des cas. Ce genre de rpm ne prends pas en compte les conventions pour les menus, ou pour le placement des fichiers. Et je ne parle même pas de la politique de nommage des paquets ou des dépendances qui se retrouve totalement ignoré. si le but est d'installer des rpms crades pour polluer le système, oui, ça permet d'arriver plus vite à ses fins. A mon sens, il faut s'en tenir aux paquets officiels des distribs, sur debian comme sur les autres. Enfin, un projet libre est souvent le résultat d'efforts conjoints (développement, documentation, test,...). De nos jours, l'empaquetage (pour k distributions) devient une tâche intégrée au développement... La séparation n'est donc certainement pas une nécessité. Non. Chacun fait son boulot. La mise en paquet est géré par le distributeur, au niveau de la distribution. Je ne voit donc pas l'intérét de placer les mêmes fichiers à 2 endroits différents. Chacun distribution posséde sa politique de gestion des versions des paquets, et ne pas la suivre ne peut qu'ajouter une confusion inutile. Pour terminer, un truc bien rageant que chacun ici a probablement vécu... quand on achète un magazine/CD avec des _tonnes_ de sources gentiment fournis (sympa quand on a(vait) pas l'ADSL ;-) alors qu'il n'y a bien souvent pas de .deb, ni de debian/, en revanche il y souvent le rpm et le .spec :-(( Et ça conduit les gens à installer des rpms venant de n'importe ou sur leur distribution, et à la foutre en l'air à petit feu. Pour ma part, je ne voit pas pourquoi on devrait favoriser tel distro par rapport a tel autre, et inciter les gens à ne pas prendre des paquets officiels. Il est peut être facile pour nous de voir si un paquet est de qualité par rapport à un autre, mais c'est pas le cas de tout le monde. Et même si ça semble facilité la vie sur le court terme, les effets secondaires sur le long terme risque d'être plus que nuisible. -- Michaël Scherer
Re: debian/ et upstream
Tous ça pour dire que même entre fichiers .deb il peut y avoir des problèmes si ils ne font pas parti de la même distribution, homogène et suivant des règles communes. Ben c'est quand même prévisible, non ? du temps où j'utilisais du Ximian, ça marchait bien. Évidemmment, je _savais_ qu'en faisant des mixtures je prenais des risques... et donc, à un moment donné j'ai fais la bascule. Point. Et même si l'upstream avait inclu un debian/ rien ne dit que Debian et/ou Ximian ne le modifiront pas en fonction de règles différentes. Euh, dans mon esprit, en supposant qu'upstream fasse correctement les choses (c'est souvent le cas non ?;-), je supposais qu'a priori le debian/ était celui de la debian oficielle, éventuellement maintenu par le DD officiel... Et je suppose qu'il ne serait pas difficile de trouver un exemple où le paquet fait par upstream serait plus correct que celui fait par un DD... ;-) Mais bon tous ça c'est des suppositions et quasiment des procès d'intention (bonnes ou mauvaises), ça n'explique toujours pas en quoi _techniquement_ (i.e objectivement == sans *pré*juger la qualité du résultat) ce serait un problème... Que certains utilisent cela à mauvais escient, c'est une fatalité (on peut obtenir les mêmes bétises à partir d'un apt-get source !) En cas de divergence entre upstream et debian, où est le problème ? actuellement un DD récupère les sources et y place son debian/, pourquoi cela serait soudain impossible (il existe des ajustements plus lourds que 'mv debian debian.upstram')? A+ -- mailto:[EMAIL PROTECTED] debfr-faq http://savannah.nongnu.org/download/debfr-faq/html/
Re: debian/ et upstream
Selon Sven Luther [EMAIL PROTECTED]: soudain impossible (il existe des ajustements plus lourds que 'mv debian debian.upstram')? Ca pollue le .diff.gz et rend les choses plus difficile pour le mainteneur. hmm, oui, tiens... à quel moment le diff.gz entre-t-il dans la danse ? il n'est généré qu'à la construction du paquet n'est-ce pas ? (inutile de le stocker?) Si upstream souhaite maintenir un repertoire debian, il faut souvent mieux qu'il le maintienne directement sous un autre nom (deb par exemple) que le mainteneur peut utiliser ou pas. i.e le nom est indifférent donc ... (tiens, est-ce paramétrable dans les outils ?) Ou encore, on peut arriver a une situation ou upstream devienne co-mainteneur du package, et que le mainteneur deviennent son sponsor. oui, c'est un scenario sain (et préférable évidemment). Mais nous sommes bien d'accord(?), c'est pas une difficulté technique... A+ -- mailto:[EMAIL PROTECTED] debfr-faq http://savannah.nongnu.org/download/debfr-faq/html/
Re: debian/ et upstream
On Mon, Sep 08, 2003 at 08:33:30PM +0200, Georges Mariano wrote: Tous ça pour dire que même entre fichiers .deb il peut y avoir des problèmes si ils ne font pas parti de la même distribution, homogène et suivant des règles communes. Ben c'est quand même prévisible, non ? du temps où j'utilisais du Ximian, ça marchait bien. Évidemmment, je _savais_ qu'en faisant des mixtures je prenais des risques... et donc, à un moment donné j'ai fais la bascule. Point. Et même si l'upstream avait inclu un debian/ rien ne dit que Debian et/ou Ximian ne le modifiront pas en fonction de règles différentes. Euh, dans mon esprit, en supposant qu'upstream fasse correctement les choses (c'est souvent le cas non ?;-), je supposais qu'a priori le debian/ était celui de la debian oficielle, éventuellement maintenu par le DD officiel... Et je suppose qu'il ne serait pas difficile de trouver un exemple où le paquet fait par upstream serait plus correct que celui fait par un DD... ;-) Mais bon tous ça c'est des suppositions et quasiment des procès d'intention (bonnes ou mauvaises), ça n'explique toujours pas en quoi _techniquement_ (i.e objectivement == sans *pré*juger la qualité du résultat) ce serait un problème... Que certains utilisent cela à mauvais escient, c'est une fatalité (on peut obtenir les mêmes bétises à partir d'un apt-get source !) En cas de divergence entre upstream et debian, où est le problème ? actuellement un DD récupère les sources et y place son debian/, pourquoi cela serait soudain impossible (il existe des ajustements plus lourds que 'mv debian debian.upstram')? Ca pollue le .diff.gz et rend les choses plus difficile pour le mainteneur. Si upstream souhaite maintenir un repertoire debian, il faut souvent mieux qu'il le maintienne directement sous un autre nom (deb par exemple) que le mainteneur peut utiliser ou pas. Ou encore, on peut arriver a une situation ou upstream devienne co-mainteneur du package, et que le mainteneur deviennent son sponsor. Amicalement, Sven Luther
