[freeside] Documentation

[ivan]

On Fri, Jan 12, 2001 at 11:06:55PM -0800, Kristian Hoffmann wrote:
> perl -MCPAN -pe 'install "Bundle::Freeside"'
> 
> Doesn't get much more complicated than that.  Ivan, any idea how to make a
> bundle on cpan?

man CPAN, see the _Bundles_ section.  I'm a registered CPAN author, and
can upload something when it is ready.

One concern is namespace issues; Freeside modules in the current
FS:: namespace don't belong on CPAN; see
<http://www.cpan.org/modules/00modlist.long.html#ID5_NamespaceCo>.

Some of the things that are still in Freeside have been abstracted into
proper CPAN libraries: FS::dbdef became DBIx::DBSchema, FS::SSH became
Net::SSH and Net::SCP, and *are* on CPAN now.

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

-- 
meow
_ivan