Néanmoins, reste une question à laquelle je n'ai pas trouvé de
réponse. Si mes sources sont bien au chaud dans un répertoire public
sur mon site personnel et suivies par git, je ne sais en revanche que
faire du répertoire debian nouvellement créé. Je me demande si
l'ajouter dans les sources « amont » est une bonne idée (et étant le
développeur amont, je crois que j'arriverai à m'entendre), ou bien
s'il est préférable de les archiver à part.
Néanmoins, reste une question à laquelle je n'ai pas trouvé de
réponse. Si mes sources sont bien au chaud dans un répertoire public
sur mon site personnel et suivies par git, je ne sais en revanche que
faire du répertoire debian nouvellement créé. Je me demande si
l'ajouter dans les sources « amont » est une bonne idée (et étant le
développeur amont, je crois que j'arriverai à m'entendre), ou bien
s'il est préférable de les archiver à part.
Néanmoins, reste une question à laquelle je n'ai pas trouvé de
réponse. Si mes sources sont bien au chaud dans un répertoire public
sur mon site personnel et suivies par git, je ne sais en revanche que
faire du répertoire debian nouvellement créé. Je me demande si
l'ajouter dans les sources « amont » est une bonne idée (et étant le
développeur amont, je crois que j'arriverai à m'entendre), ou bien
s'il est préférable de les archiver à part.
J'ai franchi le pas et lu le guide du nouveau responsable Debian afin
d'apprendre à empaqueter mes programmes pour les installer proprement
sur ma machine. Le paquet binaire est correctement produit, lintian me
donne quelques avertissements que je vais m'empresser de corriger. Je
suis un homme heureux.
Néanmoins, reste une question à laquelle je n'ai pas trouvé de
réponse. Si mes sources sont bien au chaud dans un répertoire public
sur mon site personnel et suivies par git, je ne sais en revanche que
faire du répertoire debian nouvellement créé. Je me demande si
l'ajouter dans les sources « amont » est une bonne idée (et étant le
développeur amont, je crois que j'arriverai à m'entendre), ou bien
s'il est préférable de les archiver à part.
Il m'a semblé également voir certains projets avec un sous-répertoire
« package » ou au nom approchant, renfermant le répertoire debian mais
également les directives pour faire un RPM par exemple. Je n'ai
nullement l'intention d'investir du temps dans l'écriture d'un fichier
spec, mais je me demande si utiliser cette structure est bonne
approche.
J'ai franchi le pas et lu le guide du nouveau responsable Debian afin
d'apprendre à empaqueter mes programmes pour les installer proprement
sur ma machine. Le paquet binaire est correctement produit, lintian me
donne quelques avertissements que je vais m'empresser de corriger. Je
suis un homme heureux.
Néanmoins, reste une question à laquelle je n'ai pas trouvé de
réponse. Si mes sources sont bien au chaud dans un répertoire public
sur mon site personnel et suivies par git, je ne sais en revanche que
faire du répertoire debian nouvellement créé. Je me demande si
l'ajouter dans les sources « amont » est une bonne idée (et étant le
développeur amont, je crois que j'arriverai à m'entendre), ou bien
s'il est préférable de les archiver à part.
Il m'a semblé également voir certains projets avec un sous-répertoire
« package » ou au nom approchant, renfermant le répertoire debian mais
également les directives pour faire un RPM par exemple. Je n'ai
nullement l'intention d'investir du temps dans l'écriture d'un fichier
spec, mais je me demande si utiliser cette structure est bonne
approche.
J'ai franchi le pas et lu le guide du nouveau responsable Debian afin
d'apprendre à empaqueter mes programmes pour les installer proprement
sur ma machine. Le paquet binaire est correctement produit, lintian me
donne quelques avertissements que je vais m'empresser de corriger. Je
suis un homme heureux.
Néanmoins, reste une question à laquelle je n'ai pas trouvé de
réponse. Si mes sources sont bien au chaud dans un répertoire public
sur mon site personnel et suivies par git, je ne sais en revanche que
faire du répertoire debian nouvellement créé. Je me demande si
l'ajouter dans les sources « amont » est une bonne idée (et étant le
développeur amont, je crois que j'arriverai à m'entendre), ou bien
s'il est préférable de les archiver à part.
Il m'a semblé également voir certains projets avec un sous-répertoire
« package » ou au nom approchant, renfermant le répertoire debian mais
également les directives pour faire un RPM par exemple. Je n'ai
nullement l'intention d'investir du temps dans l'écriture d'un fichier
spec, mais je me demande si utiliser cette structure est bonne
approche.
Salut,
On Thu, 29 Jul 2010, David Soulayrol wrote:J'ai franchi le pas et lu le guide du nouveau responsable Debian afin
d'apprendre à empaqueter mes programmes pour les installer propreme nt
sur ma machine. Le paquet binaire est correctement produit, lintian me
donne quelques avertissements que je vais m'empresser de corriger. Je
suis un homme heureux.
Tu devrais peut-être t'abonner à http://lists.debian.org/debian -devel-french
dans ce cas. :-)
Traditionnellement on recommande de ne pas inclure le répertoire deb ian
dans les sources amont. Mais la raison essentielle était que cela
complique le travail du mainteneur debian qui se retrouve avec un
répertoire debian amont en conflit avec sa propre version. Ce confli t
n'existe plus avec le nouveau format de paquet source "3.0 (quilt)" (le
répertoire debian est remplacé par le contenu du debian.tar.gz) et
tu fais donc comme bon te semble...
Il faut noter toutefois que le paquet Debian a une vie indépendante du
logiciel amont et peut être publié de nombreuses fois pour une version
amont donnée et du coup le contenu du répertoire debian amont n e sera pas
toujours synchronisé avec le paquet officiel.
Salut,
On Thu, 29 Jul 2010, David Soulayrol wrote:
J'ai franchi le pas et lu le guide du nouveau responsable Debian afin
d'apprendre à empaqueter mes programmes pour les installer propreme nt
sur ma machine. Le paquet binaire est correctement produit, lintian me
donne quelques avertissements que je vais m'empresser de corriger. Je
suis un homme heureux.
Tu devrais peut-être t'abonner à http://lists.debian.org/debian -devel-french
dans ce cas. :-)
Traditionnellement on recommande de ne pas inclure le répertoire deb ian
dans les sources amont. Mais la raison essentielle était que cela
complique le travail du mainteneur debian qui se retrouve avec un
répertoire debian amont en conflit avec sa propre version. Ce confli t
n'existe plus avec le nouveau format de paquet source "3.0 (quilt)" (le
répertoire debian est remplacé par le contenu du debian.tar.gz) et
tu fais donc comme bon te semble...
Il faut noter toutefois que le paquet Debian a une vie indépendante du
logiciel amont et peut être publié de nombreuses fois pour une version
amont donnée et du coup le contenu du répertoire debian amont n e sera pas
toujours synchronisé avec le paquet officiel.
Salut,
On Thu, 29 Jul 2010, David Soulayrol wrote:J'ai franchi le pas et lu le guide du nouveau responsable Debian afin
d'apprendre à empaqueter mes programmes pour les installer propreme nt
sur ma machine. Le paquet binaire est correctement produit, lintian me
donne quelques avertissements que je vais m'empresser de corriger. Je
suis un homme heureux.
Tu devrais peut-être t'abonner à http://lists.debian.org/debian -devel-french
dans ce cas. :-)
Traditionnellement on recommande de ne pas inclure le répertoire deb ian
dans les sources amont. Mais la raison essentielle était que cela
complique le travail du mainteneur debian qui se retrouve avec un
répertoire debian amont en conflit avec sa propre version. Ce confli t
n'existe plus avec le nouveau format de paquet source "3.0 (quilt)" (le
répertoire debian est remplacé par le contenu du debian.tar.gz) et
tu fais donc comme bon te semble...
Il faut noter toutefois que le paquet Debian a une vie indépendante du
logiciel amont et peut être publié de nombreuses fois pour une version
amont donnée et du coup le contenu du répertoire debian amont n e sera pas
toujours synchronisé avec le paquet officiel.
Bonjour David,
le répertoire debian a toute sa place dans le référentiel Git puisque c'est lÃ
qu'il est tenu à jour. Par contre, pour la publication des sources e t d'un
paquet source Debian, il y a plusieurs possibilités:
 1) Exclure le répertoire debian des sources publiées sous forme d'une archive
  compressée (genre toto-x.y.tar.bz2), et ne le distribue r que via un paquet
  source Debian, a recréer chaque fois que l'archive est mise à jour.
 2) Conserver le répertoire debian dans l'archive, qui du coup se comporte
  comme un paquet source Debian au format natif (modulo le fic hier de contrôle
  source Debian « .dsc »).
 3) Publier les sources comme un « bundle » git superficiel incluant le
  répertoire Debian, qui du coup se comporte comme un paq uet source Debian au
  format 3.0 (git) modulo le fichier de contrôle source D ebian, voir:
  http://kitenet.net/~joey/blog/entry/git_source_packages:_tak e_2/
Pour le 3), je concède que c'est tout nouveau tout chaud, que ç a ne passera pas
sur les systèmes stables, et que winzip, stuffit et file-roller ne v ont
probablement pas aimer non plus. Mais c'est le futur en marche.
Bonjour David,
le répertoire debian a toute sa place dans le référentiel Git puisque c'est lÃ
qu'il est tenu à jour. Par contre, pour la publication des sources e t d'un
paquet source Debian, il y a plusieurs possibilités:
 1) Exclure le répertoire debian des sources publiées sous forme d'une archive
  compressée (genre toto-x.y.tar.bz2), et ne le distribue r que via un paquet
  source Debian, a recréer chaque fois que l'archive est mise à jour.
 2) Conserver le répertoire debian dans l'archive, qui du coup se comporte
  comme un paquet source Debian au format natif (modulo le fic hier de contrôle
  source Debian « .dsc »).
 3) Publier les sources comme un « bundle » git superficiel incluant le
  répertoire Debian, qui du coup se comporte comme un paq uet source Debian au
  format 3.0 (git) modulo le fichier de contrôle source D ebian, voir:
  http://kitenet.net/~joey/blog/entry/git_source_packages:_tak e_2/
Pour le 3), je concède que c'est tout nouveau tout chaud, que ç a ne passera pas
sur les systèmes stables, et que winzip, stuffit et file-roller ne v ont
probablement pas aimer non plus. Mais c'est le futur en marche.
Bonjour David,
le répertoire debian a toute sa place dans le référentiel Git puisque c'est lÃ
qu'il est tenu à jour. Par contre, pour la publication des sources e t d'un
paquet source Debian, il y a plusieurs possibilités:
 1) Exclure le répertoire debian des sources publiées sous forme d'une archive
  compressée (genre toto-x.y.tar.bz2), et ne le distribue r que via un paquet
  source Debian, a recréer chaque fois que l'archive est mise à jour.
 2) Conserver le répertoire debian dans l'archive, qui du coup se comporte
  comme un paquet source Debian au format natif (modulo le fic hier de contrôle
  source Debian « .dsc »).
 3) Publier les sources comme un « bundle » git superficiel incluant le
  répertoire Debian, qui du coup se comporte comme un paq uet source Debian au
  format 3.0 (git) modulo le fichier de contrôle source D ebian, voir:
  http://kitenet.net/~joey/blog/entry/git_source_packages:_tak e_2/
Pour le 3), je concède que c'est tout nouveau tout chaud, que ç a ne passera pas
sur les systèmes stables, et que winzip, stuffit et file-roller ne v ont
probablement pas aimer non plus. Mais c'est le futur en marche.
Le 29 juillet 2010 12:07, Charles Plessy a écrit :
> 2) Conserver le répertoire debian dans l'archive, qui du coup se comporte
> comme un paquet source Debian au format natif (modulo le fichier de contrôle
> source Debian « .dsc »).
J'ai lu par deux fois cette distinction entre paquets natifs ou pas,
mais je ne trouve pas de développement qui explique si cela a une
incidence particulière. J'ai cru comprendre qu'un paquet natif
correspondait naturellement à un logiciel fait pour debian. Est-ce que
cela se fait d'utiliser le format natif pour un logiciel quelconque ?
Le 29 juillet 2010 12:07, Charles Plessy <plessy@debian.org> a écrit :
> 2) Conserver le répertoire debian dans l'archive, qui du coup se comporte
> comme un paquet source Debian au format natif (modulo le fichier de contrôle
> source Debian « .dsc »).
J'ai lu par deux fois cette distinction entre paquets natifs ou pas,
mais je ne trouve pas de développement qui explique si cela a une
incidence particulière. J'ai cru comprendre qu'un paquet natif
correspondait naturellement à un logiciel fait pour debian. Est-ce que
cela se fait d'utiliser le format natif pour un logiciel quelconque ?
Le 29 juillet 2010 12:07, Charles Plessy a écrit :
> 2) Conserver le répertoire debian dans l'archive, qui du coup se comporte
> comme un paquet source Debian au format natif (modulo le fichier de contrôle
> source Debian « .dsc »).
J'ai lu par deux fois cette distinction entre paquets natifs ou pas,
mais je ne trouve pas de développement qui explique si cela a une
incidence particulière. J'ai cru comprendre qu'un paquet natif
correspondait naturellement à un logiciel fait pour debian. Est-ce que
cela se fait d'utiliser le format natif pour un logiciel quelconque ?
Le 29 juillet 2010 12:07, Charles Plessy a écrit :
>
> 1) Exclure le répertoire debian des sources publiées sous forme d'une archive
> compressée (genre toto-x.y.tar.bz2), et ne le distribuer que via un paquet
> source Debian, a recréer chaque fois que l'archive est mise à jour.
Est-ce là un moyen de rejoindre Raphaël lorsqu'il dit que le paquet
Debian a une vie indépendante du logiciel amont ?
> 2) Conserver le répertoire debian dans l'archive, qui du coup se comporte
> comme un paquet source Debian au format natif (modulo le fichier de contrôle
> source Debian « .dsc »).
J'ai lu par deux fois cette distinction entre paquets natifs ou pas,
mais je ne trouve pas de développement qui explique si cela a une
incidence particulière. J'ai cru comprendre qu'un paquet natif
correspondait naturellement à un logiciel fait pour debian. Est-ce que
cela se fait d'utiliser le format natif pour un logiciel quelconque ?
Le 29 juillet 2010 12:07, Charles Plessy <plessy@debian.org> a écrit :
>
> 1) Exclure le répertoire debian des sources publiées sous forme d'une archive
> compressée (genre toto-x.y.tar.bz2), et ne le distribuer que via un paquet
> source Debian, a recréer chaque fois que l'archive est mise à jour.
Est-ce là un moyen de rejoindre Raphaël lorsqu'il dit que le paquet
Debian a une vie indépendante du logiciel amont ?
> 2) Conserver le répertoire debian dans l'archive, qui du coup se comporte
> comme un paquet source Debian au format natif (modulo le fichier de contrôle
> source Debian « .dsc »).
J'ai lu par deux fois cette distinction entre paquets natifs ou pas,
mais je ne trouve pas de développement qui explique si cela a une
incidence particulière. J'ai cru comprendre qu'un paquet natif
correspondait naturellement à un logiciel fait pour debian. Est-ce que
cela se fait d'utiliser le format natif pour un logiciel quelconque ?
Le 29 juillet 2010 12:07, Charles Plessy a écrit :
>
> 1) Exclure le répertoire debian des sources publiées sous forme d'une archive
> compressée (genre toto-x.y.tar.bz2), et ne le distribuer que via un paquet
> source Debian, a recréer chaque fois que l'archive est mise à jour.
Est-ce là un moyen de rejoindre Raphaël lorsqu'il dit que le paquet
Debian a une vie indépendante du logiciel amont ?
> 2) Conserver le répertoire debian dans l'archive, qui du coup se comporte
> comme un paquet source Debian au format natif (modulo le fichier de contrôle
> source Debian « .dsc »).
J'ai lu par deux fois cette distinction entre paquets natifs ou pas,
mais je ne trouve pas de développement qui explique si cela a une
incidence particulière. J'ai cru comprendre qu'un paquet natif
correspondait naturellement à un logiciel fait pour debian. Est-ce que
cela se fait d'utiliser le format natif pour un logiciel quelconque ?
J'imagine que le problème de synchronisation se pose surtout lorsqu'un
responsable n'a pas accès en écriture aux sources du logiciel. Car
dans le cas contraire, n'est-il pas naturel d'y adjoindre le
répertoire debian comme me le suggère Charles, et de travailler
directement à partir de ces sources ? D'ailleurs, le répertoire serait
ainsi disponible avec tout son historique pour un éventuel responsable
ultérieur.
De manière générale, le guide du nouveau responsable se base seulement
sur le cas d'une personne décidant d'empaqueter un quelconque logiciel
pour Debian, sans avoir aucune relation particulière avec le code ou
son auteur, et sans jamais intervenir en amont. (sauf pour communiquer
sur les bogues trouvés, résolus, etc.) Je trouve qu'il y manque un
chapitre décrivant que faire de son travail une fois le paquet
réalisé. Car concrètement, si le responsable n'associe pas son travail
aux sources, comment s'organise-t-il en général ?
> Il faut noter toutefois que le paquet Debian a une vie indépendante du
> logiciel amont et peut être publié de nombreuses fois pour une version
> amont donnée et du coup le contenu du répertoire debian amont ne sera pas
> toujours synchronisé avec le paquet officiel.
Il me semblerait logique que le répertoire amont soit mis à jour
systématiquement sur la génération d'une nouvelle révision au sens
debian par le responsable du paquet. (bien que je conçoive des
problèmes éventuels dans le cas d'un NMU par exemple)
J'imagine que le problème de synchronisation se pose surtout lorsqu'un
responsable n'a pas accès en écriture aux sources du logiciel. Car
dans le cas contraire, n'est-il pas naturel d'y adjoindre le
répertoire debian comme me le suggère Charles, et de travailler
directement à partir de ces sources ? D'ailleurs, le répertoire serait
ainsi disponible avec tout son historique pour un éventuel responsable
ultérieur.
De manière générale, le guide du nouveau responsable se base seulement
sur le cas d'une personne décidant d'empaqueter un quelconque logiciel
pour Debian, sans avoir aucune relation particulière avec le code ou
son auteur, et sans jamais intervenir en amont. (sauf pour communiquer
sur les bogues trouvés, résolus, etc.) Je trouve qu'il y manque un
chapitre décrivant que faire de son travail une fois le paquet
réalisé. Car concrètement, si le responsable n'associe pas son travail
aux sources, comment s'organise-t-il en général ?
> Il faut noter toutefois que le paquet Debian a une vie indépendante du
> logiciel amont et peut être publié de nombreuses fois pour une version
> amont donnée et du coup le contenu du répertoire debian amont ne sera pas
> toujours synchronisé avec le paquet officiel.
Il me semblerait logique que le répertoire amont soit mis à jour
systématiquement sur la génération d'une nouvelle révision au sens
debian par le responsable du paquet. (bien que je conçoive des
problèmes éventuels dans le cas d'un NMU par exemple)
J'imagine que le problème de synchronisation se pose surtout lorsqu'un
responsable n'a pas accès en écriture aux sources du logiciel. Car
dans le cas contraire, n'est-il pas naturel d'y adjoindre le
répertoire debian comme me le suggère Charles, et de travailler
directement à partir de ces sources ? D'ailleurs, le répertoire serait
ainsi disponible avec tout son historique pour un éventuel responsable
ultérieur.
De manière générale, le guide du nouveau responsable se base seulement
sur le cas d'une personne décidant d'empaqueter un quelconque logiciel
pour Debian, sans avoir aucune relation particulière avec le code ou
son auteur, et sans jamais intervenir en amont. (sauf pour communiquer
sur les bogues trouvés, résolus, etc.) Je trouve qu'il y manque un
chapitre décrivant que faire de son travail une fois le paquet
réalisé. Car concrètement, si le responsable n'associe pas son travail
aux sources, comment s'organise-t-il en général ?
> Il faut noter toutefois que le paquet Debian a une vie indépendante du
> logiciel amont et peut être publié de nombreuses fois pour une version
> amont donnée et du coup le contenu du répertoire debian amont ne sera pas
> toujours synchronisé avec le paquet officiel.
Il me semblerait logique que le répertoire amont soit mis à jour
systématiquement sur la génération d'une nouvelle révision au sens
debian par le responsable du paquet. (bien que je conçoive des
problèmes éventuels dans le cas d'un NMU par exemple)
J'imagine que le problème de synchronisation se pose
surtout lorsqu'un responsable n'a pas accès en écriture
aux sources du logiciel. Car dans le cas contraire,
n'est-il pas naturel d'y adjoindre le répertoire debian
comme me le suggère Charles, et de travailler directement
à partir de ces sources ? D'ailleurs, le répertoire
serait ainsi disponible avec tout son historique pour un
éventuel responsable ultérieur.
J'imagine que le problème de synchronisation se pose
surtout lorsqu'un responsable n'a pas accès en écriture
aux sources du logiciel. Car dans le cas contraire,
n'est-il pas naturel d'y adjoindre le répertoire debian
comme me le suggère Charles, et de travailler directement
à partir de ces sources ? D'ailleurs, le répertoire
serait ainsi disponible avec tout son historique pour un
éventuel responsable ultérieur.
J'imagine que le problème de synchronisation se pose
surtout lorsqu'un responsable n'a pas accès en écriture
aux sources du logiciel. Car dans le cas contraire,
n'est-il pas naturel d'y adjoindre le répertoire debian
comme me le suggère Charles, et de travailler directement
à partir de ces sources ? D'ailleurs, le répertoire
serait ainsi disponible avec tout son historique pour un
éventuel responsable ultérieur.
Est-ce que tu es disposé à voir ton VCS "pollué" par des b ranches et des
tags spécifiques à la maintenance Debian ?
Personellement je préfère quand le dépôt git amont ne contient pas de
fichier debian et que la branche de debianisation rajoute le réperto ire
debian. Cette branche peut être hébergée n'importe où ... mais c'est mieux
si elle est hébergée chez Debian pour que tous les co-mainteneu rs y aient
accès facilement y compris des développeurs Debian qui pré pareraient un
NMU sans être co-mainteneur habituel.
[...]
Je ne comprends pas la question. On prend une archive amont, on rajoute
les fichiers debian, on compile et on uploade chez Debian. On recommence
pour chaque nouvelle version amont (en réutilisant/adaptant le rà ©pertoire
debian de la version d'avant).
Est-ce que tu es disposé à voir ton VCS "pollué" par des b ranches et des
tags spécifiques à la maintenance Debian ?
Personellement je préfère quand le dépôt git amont ne contient pas de
fichier debian et que la branche de debianisation rajoute le réperto ire
debian. Cette branche peut être hébergée n'importe où ... mais c'est mieux
si elle est hébergée chez Debian pour que tous les co-mainteneu rs y aient
accès facilement y compris des développeurs Debian qui pré pareraient un
NMU sans être co-mainteneur habituel.
[...]
Je ne comprends pas la question. On prend une archive amont, on rajoute
les fichiers debian, on compile et on uploade chez Debian. On recommence
pour chaque nouvelle version amont (en réutilisant/adaptant le rà ©pertoire
debian de la version d'avant).
Est-ce que tu es disposé à voir ton VCS "pollué" par des b ranches et des
tags spécifiques à la maintenance Debian ?
Personellement je préfère quand le dépôt git amont ne contient pas de
fichier debian et que la branche de debianisation rajoute le réperto ire
debian. Cette branche peut être hébergée n'importe où ... mais c'est mieux
si elle est hébergée chez Debian pour que tous les co-mainteneu rs y aient
accès facilement y compris des développeurs Debian qui pré pareraient un
NMU sans être co-mainteneur habituel.
[...]
Je ne comprends pas la question. On prend une archive amont, on rajoute
les fichiers debian, on compile et on uploade chez Debian. On recommence
pour chaque nouvelle version amont (en réutilisant/adaptant le rà ©pertoire
debian de la version d'avant).
> Je ne comprends pas la question. On prend une archive amont, on rajoute
> les fichiers debian, on compile et on uploade chez Debian. On recommence
> pour chaque nouvelle version amont (en réutilisant/adaptant le répertoire
> debian de la version d'avant).
Désolé si je n'ai pas été clair. Je voulais soulever deux points.
Le premier était comment gère-t-on dans la pratique la vie du
répertoire debian. Ton dernier message est très clair sur ce point.
Par curiosité, peut-on observer quelque part les VCS hébergeant les
branches débianisées ou les répertoires debian des responsables ?
Le second point était que le guide ne fournit pas d'indications sur ce
sujet. Aucune recommandation n'est faite pour aider les développeurs à
gérer le stockage de leur répertoire debian, une fois le paquet
fonctionnel. C'est ce qui m'a emmené à débuter cette conversation.
> Je ne comprends pas la question. On prend une archive amont, on rajoute
> les fichiers debian, on compile et on uploade chez Debian. On recommence
> pour chaque nouvelle version amont (en réutilisant/adaptant le répertoire
> debian de la version d'avant).
Désolé si je n'ai pas été clair. Je voulais soulever deux points.
Le premier était comment gère-t-on dans la pratique la vie du
répertoire debian. Ton dernier message est très clair sur ce point.
Par curiosité, peut-on observer quelque part les VCS hébergeant les
branches débianisées ou les répertoires debian des responsables ?
Le second point était que le guide ne fournit pas d'indications sur ce
sujet. Aucune recommandation n'est faite pour aider les développeurs à
gérer le stockage de leur répertoire debian, une fois le paquet
fonctionnel. C'est ce qui m'a emmené à débuter cette conversation.
> Je ne comprends pas la question. On prend une archive amont, on rajoute
> les fichiers debian, on compile et on uploade chez Debian. On recommence
> pour chaque nouvelle version amont (en réutilisant/adaptant le répertoire
> debian de la version d'avant).
Désolé si je n'ai pas été clair. Je voulais soulever deux points.
Le premier était comment gère-t-on dans la pratique la vie du
répertoire debian. Ton dernier message est très clair sur ce point.
Par curiosité, peut-on observer quelque part les VCS hébergeant les
branches débianisées ou les répertoires debian des responsables ?
Le second point était que le guide ne fournit pas d'indications sur ce
sujet. Aucune recommandation n'est faite pour aider les développeurs à
gérer le stockage de leur répertoire debian, une fois le paquet
fonctionnel. C'est ce qui m'a emmené à débuter cette conversation.