ivan at 420.am
Mon Jan 15 01:18:23 PST 2001
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
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
More information about the freeside-users