Developers of Sympa

[Guillaume Rousse <address@concealed>]

Le 08/11/2013 04:19, IKEDA Soji a écrit :
> David, Guillaume and all,
>
> On Thu, 07 Nov 2013 15:55:00 +0100
> David Verdin <address@concealed> wrote:
>
> > Hi Soji,
> >
> > Le 07/11/13 01:07, IKEDA Soji a écrit :
> > > On Wed, 06 Nov 2013 16:45:05 +0100
> > > David Verdin <address@concealed> wrote:
> > >
> > > > Hi,
> > > >
> > > > Le 04/11/13 17:21, Guillaume Rousse a écrit :
> > > > > Hello.
> > > > >
> > > > > Le 03/11/2013 03:50, IKEDA Soji a écrit :
> > > > > > Hi,
> > > > > >
> > > > > > Guillaume's new directory layout seems to have a bit more room for
> > > > > > improvement.  For example subdirectories under src/ may be moved to
> > > > > > top level.
> > > > Are you talking about the trunk or the 6.2 branch?
> > > > > > Also expecting registration to CPAN, I drafted a modified layout.
> > > > > The desirability of such registration has never been discussed sofar.
> > > > > Altough I don't have any actual objection, I don't see much interest:
> > > > > - sympa does not belong to the primary target of CPAN (it is an
> > > > > application, not a reusable perl library)
> > > > > - sympa doesn't use ExtUtils::MakeMaker or Module::Build build system,
> > > > > meaning cpan clients won't be able to install it
> > > > >
> > > > > And even if desirable, there is no constraint on internal archive
> > > > > structure.
> > > > To sum up: we need to have a correct modularization and get rid of
> > > > circular references.
> > > > If this leads to porting some modules to CPAN, it is potentially
> > > > interesting. But this is not our current priority.
> > > "_Also_ expecting registration to CPAN", I wrote.  Expecting it
> > > just results the name of a few directories.
> > I think we agree on this. I just wanted to catch the occasion to precise
> > my exact thought about CPAN. I'm all for moving modules to CPAN if it is
> > udeful to the community.
>
> This is digressive comment.
>
> For example, I have been trained not to use HTML "richtext" mail.
> This is due to the belief that plain text is most portable format
> (and partly due to insecure implementation by popular Microsoft
> MUAs).  So, I perplexed when I found that Sympa slightly gives
> weight to HTML mail.  However, I hadn't wanted to persist removing
> such features.  In fact, they are very meaningful feature for
> some people.
>
> I would like not to decide something I haven't understood well
> being insensible, as much as I can.
>
>                                *
>
> Registering CPAN includes some levels of improvement (or,
> possiblly degression for anyone...).
>
> When Sympa will have been sufficiently modularized, I prospect, it
> will become nearly a module with thin skin of executables.  Perhaps
> somebodies disagree to me, but it is not so unnatural for me to
> registar Sympa in the future to CPAN.
>
> Attempt to register to CPAN encourages some standardizations.
>
> - Installation procedure using Makefile.PL is familiar with
>    many Perl users.
>
> - ExtUtils::MakeMaker (or similar modules) will simplify some
>    process to build, test or install the application.
>    E.g. If modules are in lib/ directory and each test cases is in
>    t/ directory, "test" target with test harness will automatically
>    be added into Makefile.
>
> - Additionally, we will no longer depend on autoconf/automake
>    framework.  Actually, we need it just to determine locations
>    of C compiler, some system tools and Perl itself.
>
> - We can benefit with CPAN testers on various platforms.
>    Currently, our scope tend to incline to Linux and MySQL.
>
> Note that I don't insist to register Sympa to CPAN as soon as
> possible.  I showed my point of view.
Hello Soji.

You can't just switch from autotools to ExtUtils::MakeMaker (or 
Module::Build, or whatever similar tool), because they don't have the 
same purpose. The first one (as cmake or scons) is a generic purpose 
software installer, whereas the others are meant to install components 
of an already-installed perl instance.

A generic installer use a default (or user-provided) prefix, then 
computes all relative pathes from it using standard prefixes, meaning 
something as:
- path to binaries is prefix + /bin
- path to data is prefix + /share
- path to configuration is prefix + /etc
- etc...

The difference between vendor-provided software (aka installed from 
distribution packages) and user-installed software is generally achieved 
using different prefixes (/usr vs /usr/local). This is a unix-wide 
convention.

A perl component installer queries the installed perl instance for its 
own prefix, and for pathes to uses for defined kind of additional 
component types:
- path to binaries is 'perl-defined path for binaries'
- path to perl modules is 'perl-defined path for modules'
- path to man pages is 'perl-defined path for man pages'

If you try to enforce your own prefix, then the previous list becomes
- path to binaries is prefix + 'perl-defined path for binaries - 
perl-defined prefix'
- path to perl modules is prefix + 'perl-defined path for modules - 
perl-defined prefix'
- path to man pages is prefix + 'perl-defined path for man pages - 
perl-defined prefix'

For instance, when using PREFIX='/usr/local', binaries are installed 
under /usr/local/local/bin, because my perl instance has '/usr' as its 
own prefix, but tries to ensure than every manually installed module get 
installed as expected under '/usr/local'...

Of course, your mileage may differ, as the control of those perl 
parameters are defined at compilation time (check in %Config), and 
because we don't have the same distribution. Debian perl maintainer, for 
instance, is known to enforce usage of FHS-compliant /usr/share for 
pure-perl modules, whereas Redhat one doesn't. So basically, unless you 
take care to override all those values into your installer, the same 
installation command can have different results on different platforms.

Also, the difference between vendor-provided components (aka installed 
from distribution packages) and user-installed software is generally 
achieved using different suffixes, through installdirs setting (perl, 
vendor, or site): that's just another orthogonal system.

Last, but not least, MakeMaker (and other) have knowledge of very few 
file types: executables, libraries, man page, and that's all. If you 
want to handle additional kind (configuration, data, etc...), you're on 
your own.

I've made multiple attempts to maintain MakeMaker usage for software 
than just happens to be written in Perl, such as for instance 
fusioninventory-agent. The amount of ugly hacks to be used just to 
enforce expected result allows me to say it's a bad idea. See for 
instance everything starting from line 99 here:
https://github.com/fusinv/fusioninventory-agent/blob/master/Makefile.PL

For all of those reasons, I'll oppose any proposal to switch from 
autotools to any perl-module specific installer for Sympa itself.

I don't have any opposition, tough, to extract parts of Sympa, to
turn them into general purpose reusable libraries, and distribute them 
separatly. That's for instance what have already been done with CAS 
authentication, which nows lives on CPAN as AuthCAS (but without any 
test, tough).
--
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