[freeside] Documentation (OT surely)

[Jason Spence]

On Mon, Jan 15, 2001 at 03:55:47AM -0800, ivan developed
a new theory of relativity and: 

> > 2) Freeside has been open to the public for quite some time now, and
> >    no major Linux/BSD distribution has created a package/port for it
> >    (well, maybe Debian, but I don't want to check right now).
> 
> I am now a Debian maintainer, and Debian unstable (future 2.3) will soon
> include Freeside as well as packages of the missing CPAN modules. 

I'm very glad to hear that!  I'm looking forward to being able to
apt-get it onto my Debian boxes when I need to troubleshoot.

> > 3) As a result of #2, I believe that Freeside's userbase is smaller
> >    than it could be.  I would like to fix this.
> 
> Your previous messages indicate a desire to distribute a third-party CPAN
> modules and Apache along with Freeside, not work with the Linux and BSD
> packaging systems.
> 
> I agree with the goal of producing packages for the various distributions,
> and even distributing them from the Freeside home page, in the case where
> the OS vendor has not yet picked them up (very likely RPMs, irrelevant for
> BSD ports, possibly .debs for installation against Debian 2.2 until 2.3 is
> released). 

I don't really want to reinvent the wheel and distribute a
jumbopackage with all the stuff in it anymore, although I'll be
keeping one in my back pocket for really fast deployment in
emergencies.  I'm convinced now that 99% of the time, the existing
packaging systems are adequate for installation and for messing around
with new features.  But I still like to be prepared.  I'll comply with
your wishes (the points of which you have explained quite
understandably) and not release that package to the community.

Justification: 

I know that *I* as a sysadmin dread the dreaded Page of Doom that I'll
get on Sunday at 3AM:

<fade in>

Phone: *RING*  *RING*

Me: snzzkk.. Herro?

Crazy people: Uh, Jason, the Freeside installation isn't working...

Me: ... ok...

Crazy people: Yeah, and we can't seem to find the backup tapes.  We
think that they got crushed when the roof gave way.

Me: *?*  *What?*

Crazy people: Actually, Guy just told me that it doesn't matter
anyway, because the Exabyte drives are on fire right now, and he's
trying to figure out how to pry open the backup enclosure to get to
them.  I think he said something about a crowbar.

Me: ... er, so like, when do you need Freeside back up?

Crazy people: Well, we fed Bob some espresso and he's cranking out
servers from parts now.  

Me: Can you get onto the Net?  Go get the FreeBSD cdroms and install
Freeside and PostgreSQL from the ports collection-

Crazy people: I don't know about that; I think that the looters ran
off with the 2501.  Oh yeah, there they go now.  It's raining too, so
there's water coming in from the fiber conduit and the lightwave mux
keeps complaining about something like "THIS CODE SHOULD NEVER BE
REACHED".  Did I mention that all the modems all burnt out when we had
the power surge?

Me: *boggle* Tell you what, there's a hard drive with a warm copy of
Freeside on Linux in my desk.  Go get it and have Bob stick it in the
servers and see if you can get the redundant backups from archives.

<fade out>

Call me crazy, but paranoia never hurt anybody :)

> > However, I *do* think that Freeside should provide a mechanism for
> > messing with the Apache config files, since Freeside could probably do
> > a better job of it than the user could (see user mailing list and Big
> > Fat Warnings in Freeside documentation for justification).
> 
> No.  Freeside won't mess with the system Apache configuration.  In the
> context of an install with a packaging system (RPM, .deb, or BSD ports),
> Freeside should do as I describe below: should setup and run it's own
> *instance* of apache with a custom, private configuration file, but the
> normal system binaries.

I agree with this as well.  
 
> > > > > That's useless.  Freeside doesn't need its own little copy of Apache.  It
> > > > > can depend on apache, mod_ssl and mod_perl in the packaging system, and
> > > > > run the standard system apache binary with the -f flag and it's own
> > > > > configuration file.
> > > > 
> > > > Hmm.  That's a good point.  However, wouldn't it be a win to give the
> > > > user an option at installtime to install the latest Apache?
> 
> No.  The Apache and mod_perl versions included with current distributions
> are fine.

Yeah.  Duh.  I guess you're right: anyone who's not installing on a
recent distribution is going to have much bigger problems than an old
Apache :)
 
> > Well, maybe not one that *you* will distribute, but I've already
> > created an installation system that does most of what I've described,  
> > and I think that my life is easier as a result.  Are you ok with a
> > third party doing all that work and simply integrating the stock
> > release into their packaging system? 
> 
> While you are of course legally permitted to do this, you would do so
> in spite of my objections, and support of the forked package would not 
> be on-topic on this mailing list.

I agree with your arguments and withdraw my intention to do so.
 
 - Jason