develooper Front page | perl.perl5.porters | Postings from February 2012

Re: Reaction to Redhat/Fedora modified releases

Thread Previous | Thread Next
Nicholas Clark
February 2, 2012 02:35
Re: Reaction to Redhat/Fedora modified releases
Message ID:
On Thu, Feb 02, 2012 at 04:02:26AM -0500, David Golden wrote:
> On Thu, Feb 2, 2012 at 2:47 AM, Todd Rinaldo <> wrote:

> > 2. Also strip html docs and man pages as they're duplicate to perldoc. (Is there an opinion on which forms of the docs need to be shipped with the product to comply with the license?)
> Please forget the "license" question -- I'd really mean "spirit of the
> license", not "letter of the license".  Personally, I think "man" for
> the bin scripts would be good to have and perldoc for the rest is
> fine.

What he says.

Note also that (currently) use diagnostics; relies on finding an
installed perldiag.pod

As it needs pretty much the entire file to function, I can't see a way to
bundle perldiag.pod into it that doesn't end up with installing 207K pod
twice for a full installation.

> > IMO, it would be cool if I could somehow tell Configure not to build/install anything that is dual-life. I'm not sure if a non-dual life perl would be stable enough to build the dual life modules if I did that. To me, this is the sanest approach to building out a core perl, allowing for dual-life modules to be updated separately.
> It's not possible to build everything without dual life modules, since
> some are essential to the toolchain.  I can't see anything preventing
> only a subset being installed, however.

Yes, it would have to be a restriction on what's installed.

However, right now, it's not possible to tell Configure not to build non-XS
modules. Everything it finds, it builds. The really historical assumption
was that only XS modules were in ext/, and the question that mattered was
"dynamic, static or don't?" (as I understand it)

When non-XS modules were added into ext/ (And then dist/ and cpan/) the
path of least resistance was to always build them, as

a) the rest of the extension handling in Configure assumes static or dynamic
b) there isn't a problem with being unable to build them because C libraries
   or APIs aren't available.

So currently one would have to munge to remove all the unwanted
pure-Perl dual life modules before building to avoid building them, and
before making to avoid having an installed %Config::Config that
says that they are there. (Although whether anyone's code interrogates
%Config::Config for that sort of thing, I don't know.)

> > I don't think I could provide a patch in the short time before the coming code freezes for 5.16, but I was considering taking this project on for 5.18. I'm also not sure how such a patch would be received if I did make it, since p5p would then be providing a way to build a severely stripped down perl.
> IMO, vendors are doing this anyway, so why not have a sanctioned
> (maintained!) way to do that.
> If you are looking to take it on, I would point you to the various
> "install*" files in the source .  They would need a lot of love (or
> possibly a complete rewrite) to support the ability to install only a
> subset of what is built.

Yes. Right now the logic for which modules get installed is in installib()
in ./installperl. The logic for which man pages get installed has been moved
from ./installman to Porting/ Some duplicate functionality of
./installperl and ./installman has converged, but ./installhtml is a still law
unto itself.

I'd been working on trying to make all this sane (ie one list of what gets
installed), but obviously there are a zillion other demands on my time,
and not enough hours in the week. ./installman is pretty clean.
./installperl is closer. ./installhtml is a mess.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About