Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 12/03/2014 17:16, IKEDA Soji a écrit :
> Hi,
>
> On Wed, 12 Mar 2014 16:48:12 +0100
> Guillaume Rousse <address@concealed> wrote:
>
> > Le 12/03/2014 16:19, IKEDA Soji a écrit :
> > > Developers,
> > >
> > > I'm trying to catch up systemd(1) support that was adopted by Fedora
> > > and will be shipped with coming RHEL7.  I wish to add it to 6.2 if
> > > possible (See attachments).
> > No need to reinvent the wheel, systemd is perfectly able to manage
> > services based on multiple individual components, such as nfs for instance.
> >
> > Here is the current implementation in mageia, in usage since july 2012:
> > http://svnweb.mageia.org/packages/cauldron/sympa/current/SOURCES/
>
> It is close to what I seeked.  I didn't come to realize using
> "forking" type.  I want to know how to control which daemons would
> be run --- by customizing "Wants" lines?
If you need to, yes. However, this is not a systemd issue: you can't do 
it with the current initscript either.

> However, since current init script uses non-general method to find
> running processes, some kind of improvement may be desirable.
>
> Anyhow, where would such files be placed in source tree, if we
> adopt them?
Alongside current init script, which is currently located in source tree 
(src/etc/script), with a sample logrotate configuration file and a spec 
file. As previously discussed, this is an unfortunate mix between main 
Sympa code, and some peripheral concerns.

First relocation proposal:
A new top-level directory, called 'misc', 'other', or whatever else, 
that would contains multiple subdirectories for various kind of files, ie:
misc
├── conf: logrotate, initscript, systemd units
├── ext
│   └── oauth: OAuth extension from M. Overmeer
└── utils: ldap_alias_manager.pl, mysql_alias_manager.pl, and similar 
poorly-coded stuff from src/bin/

Second relocation proposal:
Consider than those logrotate, initscript and systemd units are just 
generic samples, and ship them as documentation under doc/samples

In both case, dropping automatic installation and customisation support 
from the build system in favor of a manual procedure, explicitely 
described in installation documentation would provides the following 
benefits:
1) configure script simplification (no need for --with-piddir, 
--with-lockdir and --with-initdir switches anymore)
2) more consistency in setup-related configuration (PIDDIR is defined as 
a constant in Sympa::Constant, while tmpdir is defined as a normal 
configuration variable in sympa.conf)

If you're targetting sysadmins installing sympa from sources (rather 
than from a distribution package), it doesn't seem unreasonable to 
transfer them the responsability of performing those specific 
post-installation duties.
--
Guillaume Rousse
INRIA, Direction des systèmes d'information
Domaine de Voluceau
Rocquencourt - BP 105
78153 Le Chesnay
Tel: 01 39 63 58 31

Attachment: smime.p7s
Description: Signature cryptographique S/MIME