[freeside] Documentation

[Kristian Hoffmann]

perl -MCPAN -pe 'install "Bundle::Freeside"'

Doesn't get much more complicated than that.  Ivan, any idea how to make a
bundle on cpan?

-Kristian

On Fri, 12 Jan 2001, Jason Spence wrote:

> On Fri, Jan 12, 2001 at 06:16:34AM -0800, ivan developed
> a new theory of relativity and: 
> 
> > > Yeah, no kidding :) I've written some stuff that automates Freeside
> > > installation (including all the Perl module stuff), but it's
> > > encumbered by a contract I did.  I'm working with a client on
> > > releasing it to the community, and so far it looks like I'll succeed.
> > > 
> > > Doing an RPM won't work very well because then you would have to
> > > package up all the Perl modules as well, and that could be messy.
> > 
> > I disagree.  Depending on perl modules that are RPM (or .deb, or bsd
> > ports) packaged is a standard thing to do that works just fine.
> 
> I don't know about now, but the last time I tried to make the RedHat
> people happy by using a pure RPM installation of Freeside, I was
> unable to locate the appropriate Perl modules that Freeside requires.
> 
> rpmfind.net shows that you can get a bunch of perl modules here:
> http://rpmfind.net/linux/RPM/CPAN/1/src/Applications_CPAN.html
> 
> but those aren't included in the standard distributions.  I mean, you
> could introduce a dependancy on those RPMs in the Freeside spec file,
> but then I can just imagine all the users going "I can't find any of
> these goddamn RPMs, this is outrageous!" and such.  Of course, we
> could point out that those RPMs need to be downloaded from
> rpmfind.net, but 1) it hasn't been very reliable or fast these days
> and 2) users don't read manuals all the time :)
> 
> Actually, we could just bundle the RPMs in with the Freeside
> distribution, if their licenses allows that... do they?  
> 
> Regardless, I can't find all the Perl modules that Freeside needs in
> the CPAN RPM archive anyway, so the install script will still have to
> either attempt to download them or the tarballs would have to be
> included with Freeside (although maybe Ivan would be worried about his
> server load/storage space (hey, are you hosting those things on your
> SDSL link, or are they colo?)).
> 
> I'm not too familiar with the BSD ports collection yet, but it seems
> to me that there are only five subdirs in /usr/ports/lang/perl/p5*, so
> I'm assuming there's only five perl modules in the BSD ports
> collection as well.  
> 
> > > I vaguely remember something about not being able to distribute
> > > anything but the original tarballs for some of the modules from
> > > CPAN or something like that, but it was a while since I last
> > > thought of packaging Freeside up.
> > 
> > I'm pretty sure you are incorrect.  All of the perl modules Freeside
> > depends on are open-source, I believe.  If not, I will no longer use them.
> 
> Oh yeah, the open source definition does say that you have to be able
> to freely distribute the software for it to be really open source,
> huh.  I'll go read the licenses for all the modules:
> 
> Array::PrintCols: GPL
> 
> Term::Query: GPL
> 
> MIME::Base64: "same terms as Perl itself"
> 
> Data::Dumper: "same terms as Perl itself"
> 
> Digest::MD5: "same terms as Perl itself" (but see RSA note at end of
> manpage)
> 
> URI: "staPi"
> 
> HTML::Parser: (Ivan's link in install.html is wrong) "staPi"
> 
> libnet: "staPi"
> 
> Locale::Codes: doesn't say (but I couldn't find a dependancy in
> Freeside on it anyway)
> 
> Net::Whois: "staPi"
> 
> libwww-perl: "staPi"
> 
> Business::CreditCard: the source file says "staPi" in the header
> 
> Data::ShowTable: GPL
> 
> MailTools: "staPi"
> 
> TimeDate: "staPi"
> 
> DateManip: "staPi"
> 
> File::CounterFile: "staPi"
> 
> FreezeThaw: "staPi"
> 
> String::Approx: dual Artistic/LGPL
> 
> DBI: dual Artistic/LGPL
> 
> DBD::mysql: "staPi"
> 
> DBD::Pg: dual Artistic/LGPL
> 
> Ok, so it looks like we can make a Freeside superdistribution that
> includes all these modules and an install script that installs them.
> Couldn't be that hard...
> 
> > >  In addition, the install script would have to
> > > locate the apache config file and then patch it with all the
> > > settings.
> > 
> > No, Freeside should not touch the system Apache config file - it should
> > run it's own instance of Apache with its own config file.
> 
> Yeah, which is why I was pointing out that it would be easier to
> relocate the installation tree for Apache using the BSDs rather than
> trying to relocate the RPM (which (I believe) is not possible without
> completely unpackaging it and repackaging it).  That way Freeside gets
> its own little Apache installation instead of having to mess with the
> system one.
> 
> > >  I've begun doing development on FreeBSD and OpenBSD lately,
> > > and I believe that the ports collection is far superior to the Linux
> > > packaging methods.
> > 
> > Bzzt.  No jihads here, thanks for playing.  (Hint: RPM != Linux)
> 
> Yes, but my point was that the set of operating systems that use RPM
> for packaging does not include BSD, so RPM != BSD.  However you're
> correct in that the .deb packaging format is different from RPM (and
> also superior IMHO).
> 
> > >  For one thing, the installation scripts are much
> > > easier, because you just redefine PREFIX and stuff to install the
> > > apache, mod_ssl, and mod_perl ports under the Freeside installation
> > > tree, and then Freeside has its own little copy of Apache.
> > 
> > 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?  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) 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?"
>  
> > > I haven't tried with Debian either, but their packaging format also
> > > has superior updating and conflict resolution tools compared to RPM,
> > > in my opinion.
> > 
> > Even though I agree with you (in fact, I'm a Debian developer now), again,
> > this isn't the place. 
> 
> I'm sorry for preaching in the list.  I'll try to limit it to
> complaining about specific problems with the packaging systems in the
> future.
> 
> Actually, I need to package cdctl (one of my OS projects) for Debian.
> Would you mind if I mailed you with a few questions I had about
> packaging it?
> 
>  - Jason
>