Re: [sympa-fr] (question packaging) 2018 hackathon report

[Martin <adresse@cachée>]

Bonjour Luc,

Le Mon, 11 Jun 2018 14:04:50 +0200,
Luc Didry <adresse@cachée> a écrit :

> lundi 11 juin 2018, 11:20:15 CEST Martin wrote:
> > Tu dis ça parce que vous n'avez pas la ressource en interne ?  
> 
> Très clairement, il n'y a pas de ressources pour ça au niveau de la
> communauté.
> 
> > Moi je partisan du packaging upstream, c'est le plus logique et le
> > plus fiable. En général le contributeur lambda lui va fournir un
> > effort ponctuel parce qu'il en aura besoin sur une période donnée
> > puis plus rien.  
> 
> En tant que développeur de plusieurs applications, je tiens à dire que
> demander au projet upstream de faire le packaging, c'est beaucoup
> demander : connaître la build chain de Debian, celle de RPM, regarder
> les dépendances du logiciel et si on peut les résoudre en utilisant
> les paquets du système — ah bah non, y a pas ça, faudrait que j'en
> fasse un paquet, pis que je le maintienne, ou alors l'embarquer
> directement dans mon paquet, ou alors c'est pas la bonne version,
> faudrait que je demande au mainteneur du paquet de mettre à jour, ah
> mais c'est Debian, ça ne sera pas mis à jour avant un ou deux ans, à
> moins qu'il ne fasse un paquet backport. Bref, quand on met le doigt
> dans l'engrenage, faut faire attention.
> (Perso, je propose de déployer mes logiciels avec Carton, qui fait un
> peu comme ce que fait virtualenv pour Python)

De toute façon, si ce n'est pas l'upstream qui le fait, un autre
forcément moins bien informé sur les rouages techniques devra le faire, 
non ?

> 
> En tant qu'adminSys, il y a certains logiciels (dont Sympa fait
> partie) que je préfère installer depuis les sources pour ne pas
> dépendre des choix du mainteneur du paquet, ou alors il faudrait que
> le mainteneur fasse un gros boulot de personnalisation (avec
> l'interface curses kivabien pour demander les choix à l'admin), donc
> plus de travail.
> 


Cet éclairage est recevable bien sur. Et encore tu n'as pas parlé de
SELinux dans le packaging ;)
Personnellement je me suis juré de ne plus jamais faire d'installation
depuis les sources sur de la prod ne serais-ce que pour éviter la
présence d'un compilateur ou de librairies de développement sur le
serveur (ce qui n'est pas applicable pour le cas Sympa). Je n'utilise
CPAN qu'en dernier recours pour la simple et bonne raison que je ne
veux pas mixer plusieurs moyens d'installation de modules. Mais bon, il
ne faut jamais dire jamais. La règle que je me suis auto établie était
surtout pertinente à l'heure d'avant-cloud... Aujourd'hui, on
instancierait une VM ou un container juste pour Sympa avec une install
depuis les sources et ça règle le problème du packaging. En fait ça le
règle pas vraiment, ça le retarde/déplace...

Pour dire la vérité, je n'ai jamais installé Sympa par moi même : j'ai
toujours repris ou supervisé des installations existantes. Mais j'ai
quand même quelques années de pratiques en tant qu'admin de l'instance
donc je connais un petit peu.

Si l'install depuis les sources à l'air tenable, c'est sûrement grâce à
sympa_wizard.pl

Après il y a les upgrades, et ça aussi c'est un problème qui est censé
être réglé par le packaging, et pas un des moindres :S

En l'état, selon mon pronostic, les admins qui connaissent bien sympa
(comme toi) savent qu'ils doivent de suite faire l'install depuis les
sources si ils veulent espérer avoir des mises à jour upstream.
Sinon, ils se risquent à installer la version officielle de debian pour
peut que la version soit pas trop inférieure à l'upstream en se disant
que les mises à jour vont venir ... et quand ça vient pas, je suppose
qu'ils finissent par devoir désinstaller la version packagée pour faire
une upgrade depuis les sources : pas trés marrant :)

> > Si vous en avez les ressources, mon (petit) avis perso est que le
> > packaging sympa - c'est à dire le mode de distribution du logiciel
> > sur le long terme - devrait être un projet menée en interne avec le
> > soutien de la communauté, et non pas l'inverse.  
> 
> La communauté n'a tout simplement pas les ressources pour l'instant.
> Le hackathon de l'année dernière, c'était « La communauté prend les
> rênes », cette année c'est « Bon, faudrait ptêt mettre quelques rêgles
> dans la communauté, parce que tout le monde parle en même temps, on
> s'y retrouve pas » et « Au fait, où est-ce qu'on va ? » (définir des
> objectifs)
> 
> Penser à fournir des paquets dans un dépôt maintenu par la communauté
> est à mon sens inenvisageable pour l'instant (sauf si quelqu'un
> d'extérieur vient et propose de faire ce boulot, que les mainteneurs
> de paquets n'aient plus qu'à uploader). Une fois la communauté
> organisée, un rythme de croisière trouvé, le projet reparti sur les
> rails, ça pourra s'envisager.
> 
> En gros, aujourd'hui, c'est le bazar, il faut un minimum de cathédrale
> pour que des dépôts puissent voir le jour.
> 
> NB : tout ceci n'est que mon avis, mais je ne crois pas me tromper.
> David ou Marc, vous confirmez ?

OK, je comprends l'histoire de remettre le projet sur les rails avant
toute chose, c'est tout à fait pertinent à mon sens.
C'est sur qu'il ne faut pas proposer des trucs que la communauté ou le
projet ne serait pas en mesure de maintenir.

a+