Re: Draft manifest

Said Nicholas Clark <[email protected]>:
> > For folks who need the latest/greatest Perl, there is always the
> > Perl port, which is distributed with FreeBSD on DVD or CD in
> > binary installable format.
> 
> 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?
> And that any FreeBSD user who wishes to have the full thing (as might be
> found on some other OSes) needs to install the full perl using the ports
> system?

For the latest release, FreeBSD Perl is the full deal.

For CURRENT, we are still discussing this. What you ask above is
possible, if we go that route.

> I think that the idea of only putting the perl into the base OS that the
> base OS needs is sensible (start from nothing and add as needed, rather than
> go the other way and prune).  I'm just concerned that users may not realise
> that while it's perl as in "/usr/bin/perl" it's not perl as in what you'd
> get in /usr/local/{bin,lib,man} if you built from the source tarball.

See the other threads about perl-base vs perl-libraries.

> > Yes. And the core language must have no circular dependancies (need
> > X to build X+1). Miniperl is a problem here. Dynaloader needs to be
> > buildable using ordinary makefiles.
> 
> Currently DynaLoader is written as a conventional extension, in XS, so
> needs xsubpp to convert that to C. However, it already cheats as it is
> actually colluding with Configure to work out which .xs file to use.
> 
> To me, it would make sense to convert the XS to C, and maintain DynaLoader
> as C files, not rolled into an extension. It already has enough special
> cases (must be static, boot rather than bootstrap, special position in
> Makefile.SH) to prevent anyone sane calling it "normal".

Agreed.

> > All other modules can be built using something similar to what Perl
> > now has, with no significant FreeBSD issues. Builds need to be cross-
> > buildable, and all aspects of the build (PATHs, *FLAGS, which tools
> > to use) need to be fully specifiable (or overridable) at build time.
> > Build choices and runtime defaults need to be separately specifiable.
> 
> Cross building means cross configuring, surely? How does a cross Configure
> determine what the target can do, when it is running on the build host?
> [As other programs are able to cross build, what magic do they use?]

FreeBSD may be running on i386 but compiling for alpha. It knows what
the alpha defaults are, and does not want the i386 defaults to override them.

> > >  2: Add-on modules (base-perl and site-perl) must be able to fit
> > >     themselves into an existing perl installation so they can be
> > >     distributed in prebuilt form.
> > 
> > Yes. FreeBSD's ports system can accomodate this very well.
> 
> Is FreeBSD's ports system capable of installing perl extensions on its
> own, without needing CPAN modules?

BSDPAN :-)

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

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

> Would XS extensions from the ports system be dependent on a broken out
> ExtUtils "port", so that (say) someone wanting to install the "Socket.pm"
> module from the ports collection, would need to get the ExtUtils modules from
> the ports as a predependency?

I don't know. Does Socket.pm depend on ExtUtils as a run-time dependancy?

> > Would you like to look at the FreeBSD makefiles for Perl, to see
> > how much work we've had to do to get the above to sort-of-work?
> 
> I presume the answer is "lots" :-(

Right! :-)

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

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

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

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

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

>  < current shipped-with-core modules broken out, so people can mix and match >
> 
> 2: full perl dist
>    all the modules that will ship with 5.8
>    If you upgrade 5.8 to this, nothing will stop working.
> 
> 
> 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! ;-)

M
-- 
o       Mark Murray
\_
O.\_    Warning: this .sig is umop ap!sdn