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] > > 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. :-) > > Would minimal FreeBSD perl need MakeMaker and friends, or does the ports > > system ship things out prebuilt enough so that core FreeBSD userspace tools > > are all that is needed? > > MakeMaker would be needed to build the ports, but not to install prebuilt > ports. > 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. > > Can we divide it into > > > > 0: micro perl dist > > perl + DynaLoader, minimal libraries (enough to bootstrap whatever comes > > next). However, *no* CPAN.pm or likewise. This perl dist relies on the OS > > install system (ports, apt-get, whatever) to get anything else. > > Sounds OK. > > > This would be the sort of thing that FreeBSD, Debian, etc would have in > > the base OS for the use of the base OS. With a strong recommendation that > > if the user actually wants perl they should install the port, much like > > if they wanted to use python or ruby they'd have to install that. > > Or install the perl library as a port. That's what I meant to write :-) 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. > > micro perl dist isn't actually "perl", more "miniperl" (see below) > > But as it has Dynaloader, and can install the perl libraries, it can > become "real" perl. Yes. That's what I meant, but I wasn't clear. Thanks for clarifying. > > 1: mini perl dist > > as above, plus CPAN.pm (or equivalent) and enough to download more source > > as needed from CPAN > > 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" ? > > 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? 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. 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 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. > > 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 [And DynaLoader stops living in ext/ or being treated as an extension] as they provide functionality to make all the builtins work. The non-dynamic libs is also minimal, with only the modules needed by the above 3, and the modules needed to build more modules. Possibly also Digest::MD5 and MIME::Base64, but maybe be like Data::Dumper with a perl implementation that is used if the XS isn't there, and then only have the perl implementation shipped with the mini perl dist. [As the user can always get the XS implementation from CPAN] > > We've had discussion on p5p about how few extensions you can build without > > expecting to fail tests. The consensus reached was that perl isn't proper > > perl if dbmopen doesn't work (as it is a builtin), which in turn means that > > AnyDBM_File.pm needs to work, which in turn means that one out of > > qw(NDBM_File DB_File GDBM_File SDBM_File ODBM_File) should get built. > > AAAARRRGGGH! ;-) du -sk SDBM_File/ 121 SDBM_File admittedly not as good as: 30 NDBM_File but Andy Dougherty's argument was that we *could* expect dbmopen to work anywhere, even on systems without db, gdb or odbm or ndbm libraries, as we supply the entire source for sdbm. But if minimal perl were defined as "all perlfunc functions work, capable of building and installing extensions including extensions written in C" Most OSes would use DynaLoader, but there are some that can only do static linking. Then CPAN could supply a minimal perl source tarball that had SDBM_File, but *BSD / Linux / Solaris could take out SDBM_File and substitute whichever *DBM file module is most appropriate for them. [and this is "minimal" perl, not micro perl, where there would be no DBM file extension] On Mon, May 06, 2002 at 12:59:32PM +0200, Johan Vromans wrote: > Nicholas Clark <[EMAIL PROTECTED]> writes: > > > Is it well advertised in FreeBSD that by default although there is a > > "/usr/bin/perl" installed with some libraries, it is not (and does not > > claim to be) the fully featured (including cruft) perl source kit? > > 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. On Mon, May 06, 2002 at 12:09:04PM +0100, Mark Murray wrote: > Said Johan Vromans <[EMAIL PROTECTED]>: > > > Said Nicholas Clark <[EMAIL PROTECTED]>: > > > > micro perl dist isn't actually "perl", more "miniperl" (see below) > > > > > > But as it has Dynaloader, and can install the perl libraries, it can > > > become "real" perl. > > > > OTOH, if it cannot become 'real' perl due to some other restrictions, > > there's no need for DynaLoader. Right? Right. But it would be nice if other restrictions were solved, sufficient to allow the same perl binary to work for all. > Correct. In FreeBSD, loading the parts to make it 'real' perl could > easily be done via the ports mechanism. 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. 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. On Mon, May 06, 2002 at 01:13:37PM +0200, Johan Vromans wrote: > Nicholas Clark <[EMAIL PROTECTED]> writes: > > > Second niggly problem is Fcntl. Andy Dougherty's view (AD in the comment > > below) was that it was reasonable for a perl script to expect Fcntl to have > > been built. > > 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. Nicholas Clark -- Even better than the real thing: http://nms-cgi.sourceforge.net/
