You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@spamassassin.apache.org by Martin Puppe <pu...@jam-software.com> on 2015/10/21 10:48:31 UTC

Build-time vs run-time configuration of paths

Here is where I am coming from. I am trying to minimize the number of custom patches we have to apply before building SpamAssassin for Windows. That benefits us because we do not have to merge when SpamAssassin gets updates. And it benefits anyone else who is trying to run SpamAssassin on Windows.

That said, on Windows systems, preparing a Perl application for distribution is unfortunately not as straight-forward as on Unix systems. While the filesystem layout is standardized for Unix systems (at least for all systems running a given distribution), it is not at all for Windows systems. So, a distributor on a Unix system can simply set some of the variables described in PACKAGING when he or she runs `perl Makefile.PL`. Unfortunately, that does not work on Windows.

Currently, we are patching the various SpamAssassin scripts (sa-update, spamassassin, spamd, etc.) so that they all read a `./path.config` file at runtime. That is obviously not very Unix-y. So, it might not be a great idea to merge this into upstream, even behind `am_running_on_windows()`. (Or is it?)

I do not have any specific proposal at the moment. (A `--siteconfigpath` option for sa-udpate would probably go a long way though). I am just trying to raise awareness and solicit some opinions on the matter.

Regards,
Martin Puppe

________________________________

--------------------------------------------------------
JAM Software GmbH
Managing Director: Joachim Marder
Am Wissenschaftspark 26 * 54296 Trier * Germany
Phone: +49 (0)651-145 653 -0 * Fax: +49 (0)651-145 653 -29
Commercial register number HRB 4920 (AG Wittlich) http://www.jam-software.com

________________________________

----------------------------------------------------
JAM Software GmbH
Geschäftsführer: Joachim Marder
Am Wissenschaftspark 26 * 54296 Trier * Germany
Tel: 0651-145 653 -0 * Fax: 0651-145 653 -29
Handelsregister Nr. HRB 4920 (AG Wittlich) http://www.jam-software.de

Re: AW: Build-time vs run-time configuration of paths

Posted by "Kevin A. McGrail" <KM...@PCCC.com>.

On 10/28/2015 4:25 AM, Martin Puppe wrote:
>
> Just to clarify. Do you propose an additional `-f` command line option 
> for Windows? You specify `-f somefile` and spamassassin and friends 
> read DEF_RULES_DIR, LOCAL_RULES_DIR, LOCAL_STATE_DIR from the file?
>
Hi Martin,

Less a proposal but more an agreement that it sounds like a good attack, 
yes.

Regards,
KAM

AW: Build-time vs run-time configuration of paths

Posted by Martin Puppe <pu...@jam-software.com>.

Just to clarify. Do you propose an additional `-f` command line option for Windows? You specify `-f somefile` and spamassassin and friends read DEF_RULES_DIR, LOCAL_RULES_DIR, LOCAL_STATE_DIR from the file?

Von: Kevin A. McGrail [mailto:KMcGrail@PCCC.com]
Gesendet: Donnerstag, 22. Oktober 2015 03:30
An: Martin Puppe <pu...@jam-software.com>; dev@spamassassin.apache.org
Betreff: Re: Build-time vs run-time configuration of paths

My opinion is to add the support for Windows so I don't foresee a gigantic hurdle. Bang out whichever way works best for you because I don't want to stand in the way of progress.

But yes, a -f and an is running windows logic check that then reads a site config file sounds sane and unlikely to impact things too badly. I don't see the need for a config option but if it's needed I would support that too.
Regards,
KAM
On October 21, 2015 1:48:31 AM PDT, Martin Puppe <pu...@jam-software.com>> wrote:

Currently, we are patching the various SpamAssassin scripts (sa-update, spamassassin, spamd, etc.) so that they all read a `./path.config` file at runtime. That is obviously!

not

very Unix-y. So, it might not be a great idea to merge this into upstream, even behind `am_running_on_windows()`. (Or is it?)

Regards,
Martin Puppe

________________________________

JAM Software GmbH
Managing Director: Joachim Marder
Am Wissenschaftspark 26 * 54296 Trier * Germany
Phone: +49 (0)651-145 653 -0 * Fax: +49 (0)651-145 653 -29
Commercial register number HRB 4920 (AG Wittlich) http://www.jam-software.com

________________________________

JAM Software GmbH
Geschäftsführer: Joachim Marder
Am Wissenschaftspark 26 * 54296 Trier * Germany
Tel: 0651-145 653 -0 * Fax: 0651-145 653 -29
Handelsregister Nr. HRB 4920 (AG Wi!

ttlich)

http://www.jam-software.de

AW: Build-time vs run-time configuration of paths

Posted by Martin Puppe <pu...@jam-software.com>.

I have thought about Docker too. And on some level it is very appealing. Some kind of virtualization would obviate much of the pain that is porting SpamAssassin to Windows.

But we (here at JAM) are not doing this for ourselves. We are doing this for our customers. We would have to tell them that they need to install Docker. Or we would have to bundle it with our products, which would make the packages huge. And if they wanted to make any change, like loading a custom plugin, they would have to know how Docker and Unix work. And it would be hard to integrate with the rest of our products. So, making SpamAssassin truly portable is still the way to go for us.

Btw, no danger of starting an OS war. I prefer Unix … and vim. Let the editor war begin. ;-)

Von: Per-Erik Persson [mailto:pegpe@kth.se]
Gesendet: Montag, 26. Oktober 2015 10:13
An: dev@spamassassin.apache.org
Betreff: Re: Build-time vs run-time configuration of paths

Without creating to much of an OS war here I think it would be quite easy to run spamassassin inside a docker container on windows, thus eliminating a lot of problems.
Perhaps this is the the way to go?
Den 2015-10-22 kl. 03:30, skrev Kevin A. McGrail:
My opinion is to add the support for Windows so I don't foresee a gigantic hurdle. Bang out whichever way works best for you because I don't want to stand in the way of progress.

Currently, we are patching the various SpamAssassin scripts (sa-update, spamassassin, spamd, etc.) so that they all read a `./path.config` file at runtime. That is obviously

not

very Unix-y. So, it might not be a great idea to merge this into upstream, even behind `am_running_on_windows()`. (Or is it?)

Regards,

Martin Puppe

________________________________

JAM Software GmbH

Managing Director: Joachim Marder

Am Wissenschaftspark 26 * 54296 Trier * Germany

Phone: +49 (0)651-145 653 -0 * Fax: +49 (0)651-145 653 -29

Commercial register number HRB 4920 (AG Wittlich) http://www.jam-software.com

________________________________

JAM Software GmbH

Geschäftsführer: Joachim Marder

Am Wissenschaftspark 26 * 54296 Trier * Germany

Tel: 0651-145 653 -0 * Fax: 0651-145 653 -29

Handelsregister Nr. HRB 4920 (AG Wi!

ttlich)

http://www.jam-software.de

Re: Build-time vs run-time configuration of paths

Posted by Per-Erik Persson <pe...@kth.se>.

Without creating to much of an OS war here I think it would be quite 
easy to run spamassassin inside a docker container on windows, thus 
eliminating a lot of problems.
Perhaps this is the the way to go?

Den 2015-10-22 kl. 03:30, skrev Kevin A. McGrail:
> My opinion is to add the support for Windows so I don't foresee a 
> gigantic hurdle. Bang out whichever way works best for you because I 
> don't want to stand in the way of progress.
>
> But yes, a -f and an is running windows logic check that then reads a 
> site config file sounds sane and unlikely to impact things too badly. 
> I don't see the need for a config option but if it's needed I would 
> support that too.
> Regards,
> KAM
>
> On October 21, 2015 1:48:31 AM PDT, Martin Puppe 
> <pu...@jam-software.com> wrote:
>
>     Here is where I am coming from. I am trying to minimize the number of custom patches we have to apply before building SpamAssassin for Windows. That benefits us because we do not have to merge when SpamAssassin gets updates. And it benefits anyone else who is trying to run SpamAssassin on Windows.
>
>     That said, on Windows systems, preparing a Perl application for distribution is unfortunately not as straight-forward as on Unix systems. While the filesystem layout is standardized for Unix systems (at least for all systems running a given distribution), it is not at all for Windows systems. So, a distributor on a Unix system can simply set some of the variables described in PACKAGING when he or she runs `perl Makefile.PL`. Unfortunately, that does not work on Windows.
>
>     Currently, we are patching the various SpamAssassin scripts (sa-update, spamassassin, spamd, etc.) so that they all read a `./path.config` file at runtime. That is obviously!
>        not
>     very Unix-y. So, it might not be a great idea to merge this into upstream, even behind `am_running_on_windows()`. (Or is it?)
>
>     I do not have any specific proposal at the moment. (A `--siteconfigpath` option for sa-udpate would probably go a long way though). I am just trying to raise awareness and solicit some opinions on the matter.
>
>     Regards,
>     Martin Puppe
>
>     ------------------------------------------------------------------------
>
>
>
>
>     ------------------------------------------------------------------------
>
>     JAM Software GmbH
>     Managing Director: Joachim Marder
>     Am Wissenschaftspark 26 * 54296 Trier * Germany
>     Phone: +49 (0)651-145 653 -0 * Fax: +49 (0)651-145 653 -29
>     Commercial register number HRB 4920 (AG Wittlich)http://www.jam-software.com
>
>     ------------------------------------------------------------------------
>
>
>
>
>     ------------------------------------------------------------------------
>
>     JAM Software GmbH
>     Geschäftsführer: Joachim Marder
>     Am Wissenschaftspark 26 * 54296 Trier * Germany
>     Tel: 0651-145 653 -0 * Fax: 0651-145 653 -29
>     Handelsregister Nr. HRB 4920 (AG Wi!
>       ttlich)
>     http://www.jam-software.de
>

Re: Build-time vs run-time configuration of paths

Posted by "Kevin A. McGrail" <KM...@PCCC.com>.

My opinion is to add the support for Windows so I don't foresee a gigantic hurdle.  Bang out whichever way works best for you because I don't want to stand in the way of progress. 

But yes, a -f and an is running windows logic check that then reads a site config file sounds sane and unlikely to impact things too badly.  I don't see the need for a config option but if it's needed I would support that too.
Regards,
KAM

On October 21, 2015 1:48:31 AM PDT, Martin Puppe <pu...@jam-software.com> wrote:
>Here is where I am coming from. I am trying to minimize the number of
>custom patches we have to apply before building SpamAssassin for
>Windows. That benefits us because we do not have to merge when
>SpamAssassin gets updates. And it benefits anyone else who is trying to
>run SpamAssassin on Windows.
>
>That said, on Windows systems, preparing a Perl application for
>distribution is unfortunately not as straight-forward as on Unix
>systems. While the filesystem layout is standardized for Unix systems
>(at least for all systems running a given distribution), it is not at
>all for Windows systems. So, a distributor on a Unix system can simply
>set some of the variables described in PACKAGING when he or she runs
>`perl Makefile.PL`. Unfortunately, that does not work on Windows.
>
>Currently, we are patching the various SpamAssassin scripts (sa-update,
>spamassassin, spamd, etc.) so that they all read a `./path.config` file
>at runtime. That is obviously not very Unix-y. So, it might not be a
>great idea to merge this into upstream, even behind
>`am_running_on_windows()`. (Or is it?)
>
>I do not have any specific proposal at the moment. (A
>`--siteconfigpath` option for sa-udpate would probably go a long way
>though). I am just trying to raise awareness and solicit some opinions
>on the matter.
>
>Regards,
>Martin Puppe
>
>________________________________
>
>
>
>--------------------------------------------------------
>JAM Software GmbH
>Managing Director: Joachim Marder
>Am Wissenschaftspark 26 * 54296 Trier * Germany
>Phone: +49 (0)651-145 653 -0 * Fax: +49 (0)651-145 653 -29
>Commercial register number HRB 4920 (AG Wittlich)
>http://www.jam-software.com
>
>________________________________
>
>
>
>----------------------------------------------------
>JAM Software GmbH
>Geschäftsführer: Joachim Marder
>Am Wissenschaftspark 26 * 54296 Trier * Germany
>Tel: 0651-145 653 -0 * Fax: 0651-145 653 -29
>Handelsregister Nr. HRB 4920 (AG Wittlich) http://www.jam-software.de