Debian package improvements

[gelnior]

From Duck, Debian developer:

Il faudra penser à s/UNRELEASED/unstable/ dans le changelog. Pour ce qui est du BR à clore, il faut chercher si quelqu'un a déjà créé un BR, voir avec lui pour le owner (bts owner) sans que ça soit du hijacking, sinon le créer selon le modèle usuel.

Dans debian/patches/ tu noteras qu'il y a un patch debian-changes-0.6.0. En fait quand tu modifies les sources comparativement à ton tarball, et que tu lance un build en gardant ces modifications, il crée automatiquement un patch, car en fait quand tu partage ton package source avec d'autres gens, les sources originelles et les infos debian permettent de regénérer le workdir et de build identiquement. Concernant ce patch :

• la partie EGG-INFO est un répertoire généré pour les eggs, qui doit être effacé à la fin du build. en gros il faut pouvoir builder le programme en boucle sans que ça ne casse rien et en obtenant le même résultat. peut-être que ça vient d'un build qui a échoué, à vérifier
• la partie d2to1 : je ne sais pas ce que c'est, à vérifier
  Donc au final tu ne devrais pas avoir besoin de patches, sauf si tu as besoin d'influer sur le build pour des raisons spécifiques à Debian qui ne seraient pas possible en passant des options aux outils.

Concernant debian/postinst :

• vu que ton user et ton group sont les même, tu peux utiliser l'option --group de adduser pour créer le groupe en même temps. Dans tous les cas, si tu préfères garder séparé en deux commandes pas de soucis, mais penser à régler le problème suivant : ton grep pour le groupe va matcher tous les groupes commençant pas "newebe" et pas forcément celui voulu, et en plus leaker sur stdout
• pour la config, tel que c'est fait à chaque mise à jour du package elle sera écrasée et ça va emmerder le user (bug serious, voir policy). En fait tout ce que tu installes dans /etc (avec un debian/install par exemple) sera considéré comme fichier de config, et l'utilisateur sera interrogé avant d'écraser (le fameux message de dpkg), donc il te suffit juste de fournir un fichier, et s'il change dans le temps, dpkg proposera de l'écraser ou le renommera en .dpkg-new automatiquement
• pour le certif, je pense qu'il est bon de mettre un message pour dire au user de le remplacer par un maison. J'ai aussi vu l'utilisation de /dev/urandom dans certains package, probablement pour éviter de bloquer indéfiniment en cas de panne d'entropy (et comme c'est un certif temporaire de toute façon). Il y a un exemple dans debian/dovecot-core.postinst du package dovecot
• concernant le certif à nouveau, il ne faut le créer que s'il est absent, et ne pas écraser la config de l'utilisateur
• pas de sudo, le script de postinst est déjà root
• pourquoi faire des touch ? je ne comprends pas l'utilité
• pas besoin de /var/log/newebe ?
• il manque probablement un chmod après la création du certif (et pas systématiquement à chaque upgrade pour garder la conf custom du user) pour s'assurer que l'utilisateur newebe pourra lire la clef privée

Il manque un debian/postrm qui défait les choses de postinst en cas de purge :

• virer le user et group newebe
• virer les répertoire où des fichiers sont générés dans le postinst ou au runtime, car depkg refusera de virer des données user, il supprimera uniquement les données dans le package

Quelques questions, orientée upstream cette fois :

• pourquoi forcer l'utilisation de supervisor ? en quoi un start-stop-daemon ou autre outil ne pourrait pas lancer l'appli ?
• l'outil écoutant sur un port il pourrait être intéressant de faire une demande à l'IANA pour avoir un port dédié. En tous les cas la config par défaut ne montre aucun exemple pour régler le port, c'est dans le README.rst mais il n'est pas très adapté à un usage Debian et de toute façon pas inclus dans le package

[gelnior]

Va sur http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnpp;dist=unstable
ça affiche les bug d'un pseudo-package appelé "wnpp", ce qui signifie "Work-Needing and Prospective Packages", et qui sert notamment mais pas que pour dire qu'on travaille sur un nouveau package. Dans ce cas précis on met dans le sujet du ticket "ITP" (Intent to Package). Il y a d'autres possibilités comme "O" (orphan) pour dire qu'on abandonne un package par exemple.

Sur cette page il faut chercher si newebe apparait. S'il y a une ITP, alors quelqu'un est en train de créer un package, ça permet de l'annoncer et d'éviter de refaire le même travail. S'il y a une RFP (Request for Package), alors un utilisateur demande s'il est possible de créer ce package ; dans ce cas si on désire le packager on transforme la RFP en ITP (en renommant le BR) et on "own" le bug (on marque qu'on est responsable du bug). Tu peux le faire par mail ou avec la commande 'bts'.

Dans le cas présent, il n'y a rien si j'ai bien lu, donc il faut que tu crées une ITP. Pour cela, regarde ici -> http://www.debian.org/Bugs/Reporting
Précise que tu as un mentor (et tu peux mettre mon nom si besoin). Respecte bien les conventions, notamment de décrire sommairement le soft que tu vas packager en regardant la doc et les exemples.

Mon package python se base sur un fichier setup.cfg qui est le
fichier rentrant dans la norme à venir des packages python. d2to1
permet de garder un setup.py et de rester compatible avec l'ancienne
norme qui se base sur le setup.py.

Je vois. Je ne connais que le setup.py en fait, je n'ai pas fait de packaging Python depuis un moment.

En fait cet outil est déjà dans le package python-d2to1. Je te conseille donc de virer d2to1 de tes sources upstream. C'est de que faisait je patche je crois, donc tu peux le virer, et tout le répetoire 'debian/patches' devenu inutile par la même occase. Tu peux Build-Depends dessus et le générer à la volée, ça sera très élégant .

parce que debian supprime mes fichiers init.py dans certains
dossiers. Leur absence provoque des problèmes d'import python. Je suis
donc obligé de les recréer.

Ça n'est pas normal du tout, il doit y avoir un bug ou une explication quelque part, il faudra chercher.

Si, en fait je mets les logs dans /var/lib/newebe actuellement.

Ce n'est pas FHS compliant.

• il manque probablement un chmod après la création du certif (et pas systématiquement à chaque upgrade pour garder la conf custom du user) pour s'assurer que l'utilisateur newebe pourra lire la clef privée
  quels droits sont nécessaires ?

Je te conseille de faire que la clef privée appartienne au groupe newebe et de donner les droits de lecture au groupe (mais pas à other). Comme ça ton user newebe pourra uniquement lire la clef et personne d'autre.

parceque start stop daemon ne fonctionne pas avec newebe ou est trop
compliqué à utiliser pour moi. Après de nombreux essais infructueux,
j'ai laissé tombé pour une install plus directe que permet supervisor
(ceci dit newebe est plus stable désormais, ça marcherait peut être).

Dans ce cas, vu qu'utiliser supervisor n'apporte absolument rien fonctionnellement, tu vas clairement te faire pourrir pour avoir forcé à installer une dépendance inutile.
On pourra jeter un œil ensemble sur ce point si tu veux.

[gelnior]

Résumé du reste à faire:

• group à créer en même temps que l'utilisateur, normalement c'est possible.
• mettre les logs, les fichiers de config et les indexes dans les répertoire dédiées (var/log, /etc et var/lib/)
• Réaliser le package sous debian pas ubuntu 12.04 actuellement car les packages ne correspondent pas forcément.
• trouver un moyen de se débarasser des dossiers egg qui restent à la fin du build. C'est probablement dû au fait que ces dépendances n'existent pas dans les paquets debian. Le setup.py est donc obligé de les builder
• idem pour les egg d2to1, il ne devrait pas y avoir besoin de l'inclure dans le tarball initial
• proposer à l'utilisateur de renouveler les certifs
• utiliser start/stop/daemon au lieu de supervisord
• comprendre pquoi il est nécessaire d'ajouter des fichiers init.py lors de l'installation
• résoudre les warnings debian suivants:

W: newebe source: maintainer-script-lacks-debhelper-token debian/postinst
W: newebe source: maintainer-script-lacks-debhelper-token debian/postrm
W: newebe source: package-needs-versioned-debhelper-build-depends 8
W: newebe source: build-depends-on-python-dev-with-no-arch-any
W: newebe-server: copyright-without-copyright-notice
W: newebe-server: extended-description-contains-empty-paragraph
W: newebe-server: non-standard-dir-in-usr usr/newebe/
W: newebe-server: file-in-unusual-dir usr/newebe/LICENSE
W: newebe-server: extra-license-file usr/newebe/LICENSE
W: newebe-server: file-in-unusual-dir usr/newebe/MANIFEST.in
W: newebe-server: file-in-unusual-dir usr/newebe/README.rst
W: newebe-server: file-in-unusual-dir usr/newebe/setup.cfg
W: newebe-server: file-in-unusual-dir usr/newebe/setup.py
W: newebe-server: zero-byte-file-in-doc-directory usr/share/doc/newebe-server/copyright
W: newebe-server: package-contains-vcs-control-file usr/share/pyshared/newebe/client/.gitignore
W: newebe-server: binary-without-manpage usr/bin/newebe_server
W: newebe-server: maintainer-script-ignores-errors postrm
W: newebe-server: maintainer-script-needs-depends-on-adduser postins