Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 10/01/2014 16:55, IKEDA Soji a écrit :
> > Hello list.
> >
> > I just implemented this proposal under trunk, with a few modifications.
> >
> > 1) I used 'src/bin' instead of 'src/script' for consistency with
> > 'src/sbin' and 'src/libexec'.
Actually, I should have made the opposite, meaning renaming 'libexec' to 
'wrappers' and 'sbin' to 'daemons', to avoid confusion with their 
intended installation directories.

Here are current list of binaries in those 3 directories, alongside with 
their current installation path, with a FHS-style installation:

src/sbin:
* archived.pl     -> $prefix/sbin
* bounced.pl      -> $prefix/sbin
* bulk.pl         -> $prefix/sbin
* sympa.pl        -> $prefix/sbin
* task_manager.pl -> $prefix/sbin

They all install under system-wide system binaries directory, which 
seems OK.

src/libexec:
* alias_manager.pl       -> $prefix/libexec
* mysql_alias_manager.pl -> $prefix/libexec (1)
* ldap_alias_manager.pl  -> $prefix/libexec (1)
* aliaswrapper           -> $prefix/libexec
* bouncequeue            -> $prefix/libexec
* familyqueue            -> $prefix/libexec
* queue                  -> $prefix/libexec
* virtualwrapper         -> $prefix/libexec

They all install under system-wide binaries-for-other-binaries 
directory, which seems OK. We could eventually use 
$prefix/libexec/sympa, tough.

(1) should probably get dropped completly, or at least moved to a 
contrib/unsupported/whatever directory, given their current state.

src/bin:
 * sympa_soap_client.pl     -> $prefix/bin
 * sympa_wizard.pl          -> $prefix/bin
 * arc2webarc.pl            -> $prefix/share/sympa/bin
 * arcrepair.pl             -> $prefix/share/sympa/bin
 * crypt_passwd.pl          -> $prefix/share/sympa/bin
 * find_missing_messages.pl -> $prefix/share/sympa/bin
 * init_comment.pl          -> $prefix/share/sympa/bin
 * mod2html.pl              -> $prefix/share/sympa/bin
 * p12topem.pl              -> $prefix/share/sympa/bin
 * testldap.pl              -> $prefix/share/sympa/bin (1)
 * testlogs.pl              -> $prefix/share/sympa/bin
 * tpl2tt2.pl               -> $prefix/share/sympa/bin

Here we have an arbitrary mix of system-wide ($prefix/bin) and 
application-specific private binaries directory, which is an error of mine.

I'd rather move sympa_wizard.pl under $prefix/sbin, as it requires admin 
privileges to be run (or eventually $prefix/share/sympa/bin, but it 
would remove it from PATH).

I'm note sure about sympa_soap_client.pl: what is its expected usage ? 
If it is just a way to integrate another sympa server as an external 
source, it could be moved to src/libexec, as other 'glue' executables. 
If it is intended to be a standalone usage, it could eventually left 
under $prefix/bin, or moved to $prefix/share/sympa/bin if really

(1) should get dropped completly, given its lack of added value over 
plain ldapsearch tool.

> > 2) I moved samples files into already-existing doc/samples subdirectory
> > instead of creating a new top-level one
> >
> > 3) I had to use default/mail_tt2 and default/web_tt2 instead of
> > default/templates/mail and default/templates/web, to simplify Makefile
> > readability (same distribution and installation layout). I just noticed
> > we also have a 'default/create_list_templates' directory, there is still
> > room for better naming consistency here.
> >
> > 4) I kept logrotate and init script in src/etc, as I don't see any
> > better place for them right now. I think we should rename the 'ext'
> > top-level subdirectory to a more generic 'misc' or 'contrib' directory,
> > and put this kind of content here:
> > - contrib/ext: the current ext subdirectory
> > - contrib/redhat: spec file, logrotate, init script, and other sysadmin
> > stuff
> > - contrib/bin: misc scripts that don't match our coding standard
>
> I feel the same as Guillaume about logrotate and init scripts.
>
> - Such files seem occasionally placed at top of the source tree of
>    numerous source packages, probably because of similar reason
>    described by Guillaume.
I'd rather avoid using the top-level directory for storing those kind of 
files, they are way too much of them.

> - sympa.in, sympa.spec.in and logrotate seem intended to be used
>    on Linux, especially on RHEL/CentOS.  But sympa.generic can also
>    be used on Solaris, *BSD and so on.  All of those files might be
>    placed under the same place (contrib/ looks less appropriate: they
>    are not always specially contributed).
Let's call this directory 'ext', 'misc', 'various', 'unsupported', 
'staging', whatever, then. My point is just making a clear separation 
between core sympa code, maintained by us, and and everything else, 
which should rather be left to final users, or distribution packagers.

> We might make some considerations on things under ext/ where
> currently Markov's work is held.
>
> - Files under ext/Plugin/ add plugin framework to Sympa (it is
>    promising, I guess).  So they would be integraded into Sympa.
>    In short, they would be moved into src/lib/.
If they are ready to use, sure. But remember than integrating them does 
constitute a strong commitement to maintaining thise code, while keeping 
it separated doesn't. And for me, we have better priorities.

> - Others are abstract implementations of plugins.  Where to place
>    them may depend on where to these plugins will be maintained.
>    I'd like to hear Markov's inension.
>
>
> > 5) I moved the various README.* files under doc subdirectory. I think
> > one should quickly review them, and eventually delete them: that's not
> > worth duplicating content already present in the sympa manual.
>
> Former src/etc/README_etc and src/etc/README both seem intended to
> be installed at top of $confdir so that they will indicate that
> directory will be used for the purpose of customization.  I guess
> they may not be required.
I just dropped them.

Also, the sympa guide is heavily outdated...
--
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