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:[email protected]] Gesendet: Montag, 26. Oktober 2015 10:13 An: [email protected] 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. 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 <[email protected]><mailto:[email protected]> 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
