> On Mon, May 06, 2002 at 11:31:26AM +0100, Mark Murray wrote: > > Said Nicholas Clark <[EMAIL PROTECTED]>: > > > > Is FreeBSD's ports system capable of installing perl extensions on its > > > own, without needing CPAN modules? > > > > BSDPAN :-) > > Now, I am probably being thick here, but trying to RTFM (the FreeBSD Handbook) > I find section 4 is on the ports collection, which mentions that packages are > preferable were possible. However, I can't find anything in there > documenting packages. [I don't have /usr/ports installed due to space > constraints]
I know there is a guide to porters somewhere in the documentation set. A quick 'find' showed up something called porters-handbook. Dig around for that. > > > So would minimal FreeBSD perl ship without CPAN.pm, because FreeBSD users > > > would install from the ports system, not the CPAN mirrors? > > > > Sorta. BSDPAN, plus our pkg_* utils, similar in concept to RPM technology. > > But hopefully better. RPM let me remove the python libs that up2date > [the Redhat keep-up-with-the-bugfixes program] uses without issuing any form > of about to break dependencies warning. > > If you'd said "like Debian's .debs" there would have been no rant. :-) Debian's .debs and our ports are very similar :-). > > I don't know. Does Socket.pm depend on ExtUtils as a run-time dependancy? > > I believe that nothing outside the ExtUtils hierarchy uses ExtUtils at > run-time. So a package of Socket.so and Socket.pm could be used by a > perl with just DynaLoader. No problem then. > The important bit being that it would be really useful if we can make it > so the user doesn't need to download a new perl binary to do this. > Just add dynamic linked extension to the base system's perl. How? "Adding dynamic linked extension" is either rebuilding the perl binary or loading another one. (Binary editing would be laughed out of town!) > > FreeBSD has its own port distribution system. BSDPAN would be used, > > and many users would want to use the freeBSD port system to build > > the modules. > > Presumably one of the advantages it offers over CPAN is "uninstall" ? RIGHT! :-) > > > I'm not sure if this includes Socket.pm, let alone LWP type modules, as > > > CPAN can work with lynx and so forth. I suspect it should contain > > > Socket.pm and enough simple pure perl modules to get things by http and > > > ftp (passive and active) > > > > The current perl dependancy tree would make this a _big_ list. > > You sound like you've got the dependency tree written down somewhere, which is > more than I have. How do you generate it? Naah. Its more in my head as I worked this out one time looking for stuff to delete. It came down to needing everything in 5.6.0 except CGI. > It would be useful to be able to trim it so that a self-hosting perl > distribution (ie one capable of getting and installing more modules without > outside help) could be as small as possible. You could go for a dual system. Self-hosted-perl-only or self-hosted-but-using-OS-apps. > Then again, this might be a stupid thing, because to be properly self-hosting > the perl would have to have some way of uncompressing modules. So either it > ships with Compress::Zlib, or carries a pure perl decompression system, or > CPAN has (some) mirrors known to provide uncompressed modules (transparent > decompression), or (in this example - most OS' have gzip/compress these days - it would be as reasonable to assume that as it is to assume tar.) > We give up on the truly self-hosting idea and accept that the user needs to > have gzip or something functionally equivalent, and therefore also needs to > have some sort of external program capable of doing network gets. Sure. Assume a basic toolset - ftp, wget/fetch etc. > > > I think it must have Fcntl, File::Glob and SDBM_File in ext (see below) > > > > Pretty much most of what is there now. Notable exception - CGI.pm. > > Well, I meant of 5.8's ext: > > B Digest Filter MIME SDBM_File Time threads > ByteLoader DynaLoader GDBM_File NDBM_File Safe Unicode util > Cwd Encode I18N ODBM_File Socket XS > DB_File Errno IO Opcode Storable attrs > Data Fcntl IPC POSIX Sys attrs.t > Devel File List PerlIO Thread re > > the only 3 dynamic extensions would be Fcntl, File::Glob and SDBM_File The rest being "optional"? That I can swallow. No CGI? Hmmm. It was CGI that sparked off this furore :-). > [And DynaLoader stops living in ext/ or being treated as an extension] YAY! > > Since the trimmed perl is for system maintenance and configuration > > only, I'd expect it in some system specific location (e.g., > > /usr/sysconfig/tools/perl) instead of /usr/bin/perl. > > This makes sense if there are restrictions that mean that it can't be the > same binary as full-fat perl. Right. > I'm confused. DynaLoader has to be staticly linked. So if the system core > perl binary doesn't have DynaLoader linked in it would have to be replaced > with a perl that did have DynaLoader. Yes. This means that the base/minimal perl should ideally have Dynaloader. > Nothing that the magic of symlinks couldn't hide, but not ideal as one would > not like to have the space still used for 2 perl binaries if the user does > install the full perl. But if the system deletes the system maintenance perl > on upgrade, then the user can't remove the "perl port" without having to > find the system maintenance perl binary from somewhere. Which feels bad. > Downgrading should be easy, and not need external files. _No_Ways_ are we going down the symlink-hell road. Users are welcome to do that, but the out-of-box install needs to be as symlink free as reasonably possible (we played the symlink game with libcrypt, and it sucked). Base perl (including dynaloader) smells ideal to me. > > Why would Fcntl be a major requirement? Where would a bootstrapping > > process need it for? > > Anything that wanted to do fcntl or ioctl with the proper symbolic constants > would need Fcntl. And a toolkit to build it. Careful, here! A FreeBSD 'make world' would not want perl to dig around in /usr/include; the files to be grovelled through have not net been installed. M -- o Mark Murray \_ O.\_ Warning: this .sig is umop ap!sdn #text/plain; name=cv.doc [Mark Murray CV Plain Text] cv.doc #application/octet-stream; name=cv.pdf [Mark Murray CV PDF] cv.pdf
