Accéder au contenu.
Menu Sympa

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

Objet : Pour les administrateurs de serveurs de listes utilisant le logiciel Sympa

Archives de la liste

Chronologique Discussions  
  • From: Martin <adresse@cachée>
  • To: Luc Didry <adresse@cachée>
  • Cc: adresse@cachée
  • Subject: Re: [sympa-fr] (question packaging) 2018 hackathon report
  • Date: Tue, 12 Jun 2018 09:59:43 +0200

Le Mon, 11 Jun 2018 18:06:38 +0200,
Luc Didry <adresse@cachée> a écrit :

> lundi 11 juin 2018, 14:42:38 CEST Martin wrote:
> >
> > 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 ?
>
> Le mainteneur doit certes comprendre ce qu'il empaquète, mais à mon
> sens, c'est plus simple pour lui (y a la doc, il peut en avoir un
> lui-même, etc) que de demander aux développeurs d'en plus se charger
> du packaging (les développeurs ont déjà du boulot : le développement).

Je ne pensais pas au développeurs spécifiquement, c'est clair qu'ils
ont autre chose à faire (pour rester poli). Je pensais plus à
quelqu'un dont le champ d'action est le plus proche d'un "release
manager"... Je sais on peut toujours rêver.

>
> En tant que packageur, tu n'as pas besoin de connaître les détails
> techniques sur le bout des doigts, aussi bien que le dév. Normalement,
> la doc d'installation, si elle est bien faite, suffit. Et puis on
> s'arrête où ? Si tu fournis le .deb, qq'un viendra demander le .rpm,
> puis qq'un viendra demander le truc kivabien pour ArchLinux,
> Slackware, etc (ah pis le docker aussi). Donc si l'upstream laisse
> l'empaquetage aux mainteneurs des différentes distributions, c'est
> plus simple.
>
> Après, le packageur peut appartenir à l'équipe upstream (il peut même
> ne faire que ça), mais là en plus un dépôt (apt, rpm…), c'est du
> boulot en plus, et encore une fois, on risque de te demander le
> support de XXX, et YYY.

Faut savoir s'arrêter à l'essentiel, c'est sûr.
Ok avec toi pour laisser la main aux mainteneurs de distributions.

Par contre à mon avis il faudrait au moins - comme le disais Marc - au
moins un canal de distribution supporté upstream, paqueté debian (mais
indépendant du canal debian officiel).
Avec un ligne d’intégration continue, ça pourrait permettre de générer
des paquets facilement. J'ai vu que LL::NG le fait déjà, mais aussi
FusionDirectory.

>
> > 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.
>
> Je ne connaissais pas bien sympa avant d'en installer un, et
> sincèrement, si je le connais mieux aujourd'hui, je ne peux pas dire
> que je le connais si bien que ça ¯\_(ツ)_/¯
>
> Et accessoirement, je suis toujours sur 6.2.16

Donc tu as fait le 'patch -p1 < xx' récent ? :)

> : les adminsys sautent
> rarement sur la dernière version qui vient de sortir (sauf pb de sécu
> ou le fix kivabien du bug trochian).

En effet, mais justement, pour mon cas OW2 la question commencer à se
poser.

>
> > 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 :)
>
> Oui, clairement, faut choisir son camp et ne pas chercher à changer de
> méthode en cours de route, ça a 99% de chances d'être galère.

Clair, faut partir ultra simple sans promettre la lune, pas dire oui à
tout etc... Je crois qu'on connaît tous ces mécanismes ;)






Archives gérées par MHonArc 2.6.19+.

Haut de le page