sa-filter & symlinks (was: svn commit: r153131 - in spamassassin/trunk: Makefile.PL build/do)

["Malte S. Stretz" <ms...@gmx.net>]

On Thursday 10 February 2005 23:12 CET Justin Mason wrote:
> Malte S. Stretz writes:
> > On Thursday 10 February 2005 22:31 CET Daniel Quinlan wrote:
> > > Hmmm... the symbolic link is created in the SVN tree during "make",
> > > but does not get copied over during "make install" (which is really
> > > the only place it's needed, there's no need for the symlink in the
> > > SVN tree, really).
> >
> > *gnah* You're right.  I didn't test 'make install', just made sure the
> > symlink is kept while the stuff is copied to blib.  The install step is
> > done by ExtUtils::MakeMaker::Install and I had a look at the source and
> > am afraid its simply impossible to install symlinks :-(  At least
> > without rewriting most of EU::MM in our Makefile.PL.
>
> can we just add a new target to the generated makefile, and do it there?

No, the whole install thing is done via one single call to 
ExtUtils::MakeMaker::Install::install which uses File::Copy::copy 
internally.

> > I'm currently experimenting with Module::Build and that looks much more
> > promising.  I hope I can replace the Makefile.PL mess in March,
> > probably for 3.2 I guess.  That will cost us an additional build time
> > dependency but I think its worth it.
>
> ....yikes.

That's exactly what I say each time I have a look at our Makefile.PL ;~)

> Module::Build is still apparently missing a lot of things that
> ExtUtils::MakeMaker has, last time I looked.   I think it has difficulty
> installing outside of the default locations, if I recall correctly.

Those were AFAIK ironed out some time ago.  But I'm still experimenting, I'm 
currently trying to do all the stuff there which we already do in 
MakefilePL (which is already a lot easier and less hackish).  If it works, 
M::B is the only sane alternative to our EU::MM hackery.

> > I guess for now the scipt-exec-wrapper is the easier solution -- why
> > didn't Justin like the FindBin solution?
>
> It is unportable; doesn't work on some platforms, if I recall correctly,
> and also had perl version dependencies.  there's a bug in the BZ I think.

I remember that there were issues with FindBin in Perl 5.005, but those were 
fixed in 5.6 AFAICR.  I don't know on which platforms it doesn't work today 
but the bets are good that these are the ones we don't care about :)  
Whatever, we can of course also implement our own logic (take the path part 
of $0 if there's any, else search in the PATH).

> Also it doesn't fix the problem we're having -- taint issues from having
> one script exec another.

And why don't we just untaint the stuff like we do everything else??  Or 
just search the binary in the PATH ourselves (*cough* FindBin *cough*) as 
we'll probably have to call $^X anyway to make it work on Windows.

I'd like to see the reporting stuff go into its own app sa-report in which 
case we'd need a more complicated fork in the spamassassin script anyway.

Cheers,
Malte

-- 
[SGT] Simon G. Tatham: "How to Report Bugs Effectively"
      <http://www.chiark.greenend.org.uk/~sgtatham/bugs.html>
[ESR] Eric S. Raymond: "How To Ask Questions The Smart Way"
      <http://www.catb.org/~esr/faqs/smart-questions.html>