[freeside] Documentation

[ivan]

On Mon, Jan 15, 2001 at 03:06:51AM -0800, Jason Spence wrote:
> On Mon, Jan 15, 2001 at 01:04:21AM -0800, ivan said: 
> 
> [snipped Ivan's rather monosyllabic responses]
> 
> Ok, so you didn't like my ideas, eh? :)
> 
> Right then.  Here's a few things I'd like to point out:
> 
> 1) I want it to be easy to install Freeside.

I agree with you.

>  I am going to soon
>    release things that will make it easier than it is now.  You seem
>    to be arguing with that concept, but I can't tell for sure until
>    you answer the questions below.

I'm not arguing against making Freeside easier to install.  I'm arguing
against doing things in Freeside that are best handled by OS
packaging or CPAN.

> 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. 

> 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). 

For OSs without packaging, and if there is a solution to the namespace
issues,
  perl -MCPAN -e 'install Bundle::Freeside' 
should be able to download and install all the dependencies and command
line programs.  Apache configuration and mod_perl would still be done
manually.

> > Freeside will not install "its own little Apache installation".
> 
> I agree that it is the packaging system's responsibility to provide
> the Apache environment, and maybe distributing Apache with the stock
> distribution is a little much.  

It is.  Dependencies are part of what the OS's packaging system will
provide, for Apache, mod_perl, mod_ssl and the CPAN modules. 

> 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.

> > > > 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.

> > > I figure
> > > that the install script could go get the system Apache's version and
> > > compare it with the one in the superpackage (assuming that Apache is
> > > distributed with the Freeside superpackage)
> > 
> > There will be no "Freeside superpackage".
> 
> 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.

> > > and gently point out to
> > > the user that "gee Mr. User, your system apache version 1.2.3 is not
> > > as recent as my 1.3.14, would you like me to install Freeside on
> > > Apache 1.3.14?"
> > 
> > No.
> 
> This is what I'm unclear on: are you not ok with Freeside itself doing
> that, or a distribution's packaging system doing that?

I'm not okay with Freeside's installtaion doing this, or declaring a
needless dependency on the newest Apache to force a distrubution's
packaging to do this.  As I said above, the Apache and mod_perl versions
included with the current distributions are fine. 

-- 
meow
_ivan