[freeside] Documentation

Jason Spence thalakan at frys.com
Fri Jan 12 16:30:18 PST 2001


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



More information about the freeside-users mailing list