> It's been a couple of days since we started this list, so let's try to
> get going. This is a first shot to a manifest.

No need to CC me - I am on the list :-)

For those not in the know, I am FreeBSD's "perl guy", responsible
for keeping a working/usable Perl in FreeBSD. This is a difficult
job!

> This list has been started in reaction to an often heard complaint
> that Perl is becoming bigger and bigger, and its size is keeping
> people and companies from installing, and using, it. To overcome this
> problem, the current standard Perl distribution needs to be split into
> a small core part, and additional modules. The core part needs to be a
> useful subset capable of real life work, like adding the additional
> modules. (Although we may want to use industry standard installation
> tools as well.)

I am strongly in agreement with this.

The FreeBSD core OS needs not much more than the basic language,
so miniperl's functionality comes vaguely close.

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.

> An additional problem is that many of Perl's run-time defaults are
> actually established at build time. This makes it hard to produce a
> prebuilt Perl distribution that can be installed flexibly, and
> additional prebuilt modules that can be added to an arbitrary Perl
> installation.

Yes. FreeBSD needs to be able to cross-build. There are different kinds
of cross-builds, as Perl would see it;

1) Different CPU architectures
2) OS upgrades (like FreeBSD-STABLE --> FreeBSD-CURRENT)
3) Buildworlds after Perl upgrades (when miniperl has a
   risk of failing).

> I see three problems that must be solved:
> 
>  1: A perl distribution must be able to be (re)located anywhere and
>     use itself as a starting point to find its additional libraries
>     and modules.
>     The way ActiveState's rpm handles it (by patching the binaries and
>     scripts) works, but defeats the rpm functionality to verify an
>     installation.

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.

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.

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

>  3: The Perl distribution must be split into a core part, and
>     additional modules. 

If "core" is just the basic language+Dynaloader, libperl and some
documentation, then I am strongly in agreement.

> Patches welcome.

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?

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

Reply via email to