install.sh

John Rudd jrudd at UCSC.EDU
Thu Mar 11 21:55:37 GMT 2004


David Lee wrote:
>
>
> But now you seem to be in favour of a well-written, trusted "install.sh".

If well written means "asks me what I want to do", then yes.

I'm very much in favor of automated installation/upgrade tools (aferall,
my favorite unix platform was Nextstep, which had a very strong
packaging system).  As long as they don't do so in very broad strokes.
We do things here that aren't completely standard to other people's ways
of doing things, due to certain legacy issues (and other factors).

One rc script for Mailscanner+Sendmail doesn't work for us.  We
routinely do things like just stop Sendmail, just start sendmail, etc
(both by hand, and by automated scripts that are importing database
extracts from another location).  When we do that, we don't want to stop
mailscanner.  We don't want mailscanner to be involved in that event at
all.  And when we want to adjust one mechanism, it doesn't make sense
for us to be making adjustments to the startup script for a different
mechanism.  And the "keep it simple" point of view rules supreme here.
One RC script that controls sendmail, and just sendmail ... a second RC
script that controls mailscanner, and just mailscanner.

Similarly, it's not about "configure, make, etc." it's about granularity
of control.  I want to make sure that when I run "install.sh", it puts
things where I want them, not where someone else thinks they ought to
go.  Checking for dependancies is great.  Setting things up
automatically is great IF it's putting them where I want.  Setting
things up automatially is not great if it's putting them where I don't
want.

And then there's the symlink issue.  Will install.sh complain that I
told it to put things in a location that's a symlink?  Even though a) it
works for our site because our virus scanner doesn't have a problem with
that, and b) it's really required here?

I'm not worried about automated installation and checking, I'm worried
about an installation script that doesn't do what _I_ tell it to.

I'm not worried about Julian's quality of code -- I'm very happy with
that.  But, I have also noticed little things change that I didn't
really want to change ... and that has also caused me to have to by-pass
those changes at times (like when certain things changed capitalization,
and that caused a problem with check_mailscanner at one point because it
was checking for /opt/MailScanner/something when the real path was
/opt/mailscanner/something, so it never found a running copy of
mailscanner and just kept spawning new ones ... yet, there's no reason
why the code should have been enforcing said change in capitalization).
If I end up having to bypass or fix install.sh so that it works for my
environment, then I would rather not use install.sh at all.



More information about the MailScanner mailing list