i'm not saying that cpanplus's reporting is inadequate, so much as that
i'm saying that it appears to be causing some misclassification and
confusion. so, I'm trying to lay out an accurate reporting of prereq
failures that includes system dependency failures. The issue of
actually resolving the system dependency failure, package management,
etc, is to be sure, more interesting, but seems to me to be derivative,
or dependent upon an accurate diagnosis of the system dependency
failure. not to mention a being a great big tar pit.
COMMENTS ON ALIEN:
installing a package:
0. check signature
1. unpack tar ball
2. check prereqs
3. configure
4. make
5. test
6. pre-install (shut down conflicted servers)
7. install
8. post-install (re-index libraries, relink executables, install rc scripts)
the ubiquitous configure script does configuration and prereq checking
at the same time. i believe it follows an adaptive path, trying to find
the best configuration that fits with the system. So really, the set of
prereqs is a somewhat fluid thing with lots of heuristics driving it.
This complex adaptive configuration/prereq thing it does makes it
difficult sometimes to figure out how to fix it if something goes
wrong. A big problem I have with installations is making all of them
fit together, like linking mysql with one threading library with a perl
with another threading library will likely cause core dumps. If only I
could a. install perl and then b. feed perl's system discovery
information to all of gnu's configure scripts. This would be a perl
driven system installation. It would make my life easier, that's for
sure. Current configure requires you be a shell and m4 guru. i'd like
to say toss that and sub perl for both, but that won't fit well with the
embeded systems folk ... unless the system is so small they do all their
work with cross-compilers. The problem with configure is that each
configure is standalone. Some may say that's good, not bad, but I say
it would be nice if the configures could be joined together, with some
component architecture. if that was done, then perl could feed into
that and all the configures could pull from perl's initial setup. piece
of cake! Maybe somebody with gentoo has figured this one out.
The Alien manifesto is a wrapper around some external package. The
instance pointed to is for zlib, to detect it, install it, and use it.
HERE'S MY PROBLEMS WITH ALIEN:
* has to be one Alien package for each external system feature. That's
a lot of packages, all alike, except for the name of the system
library. i'd like one package to deal with libraries, and the zlib
Alien to inherit from that.
* although the Alien might be installed, the external system feature
might be removed. with CPANPLUS, the prereq would be satisfied, since
the Alien was there, but in fact it won't work, and the Alien won't be
called to make it work.
* moreover, the Alien feature might be installed, but not usable to
perl, perhaps due to build options for the Alien being incompatible with
perl's. for example, maybe the library is 64bit but perl is 32bit. It
would not be good for the Alien to install a 32bit on top of the 64bit,
that would surely tick somebody off.
* seems focused on system libraries, not more general features, like c
compiler, linker, other commands.
* the usage information supplied is insufficient. a list of include
directories and libraries, with slashes not backslashes. no other
custom compiler or linker flags are mentioned. Maybe -shared or -pic
might be found elsewhere, but what about custom SHLIB paths, or -D
defines? Sometimes the installed library is not on the system path and
you need to bind that directory (with ideosyncratic linker flags) to the
generated perl shared library module.
* where do you specify the installation location? does the prefix
method set that or interogate it?
* needs an api doc, not a manifesto.
* not adaptive, like gnu's configure. it's either the perl way or the
highway. what about php, python, java jni, mysql, postgres and apache?
* kind of heavy handed. suppose I don't want that prereq installed,
just cause I know better? Without changes to CPANPLUS, I'm going to see
a prereq for Alien::xxx, which will look like a perl package, but if I
say yes to CPANPLUS to install it, the installation of Alien::xxx has an
unannounced side effect, that of installing some system component that I
may not want, or may damage my system.
* what about if perl is a static build? Will Alien rebuild perl? What
will mod_perl say? Will Alien change perl's Config, say to add some
libraries to LDFLAGS?
* package manager package manager package manager.
basically i'm saying that when you're installing system libraries
suddenly perl is not the center of the world. I don't think Alien is
the answer. What I'd like to see are persistent component like wrappers
around system features that are available to all package builders, not
just perl.
anyways, back on the prereq issue. there is a need for a prereq checker
for a system dependency, distinguished from a perl module dependency.
I'd like to see good reporting from this, and some kind of support from
Module::Build, eu::mm, and cpanplus. i think we should simplify things,
and say that the build process is linear and that prereq checking has no
feedback to itself, and that the purpose of this step is to check for a
preset list of immutable prereqs. This step will not install stuff (but
could feed into a process that will do this later). Failures at this
stage may abort the build due to prereq failure.
WHAT TO DO IN THE MEANTIME - Q FOR JOS:
Jos, as an xs developer I am not likely to switch to Module::Build
anytime soon. I've got some more xs to build, with system
dependencies. How can my Makefile.PL throw a system dependency failure
to cpanplus? Is there any way for my Makefile.PL to throw an error and
diagnostic of any sort to CPANPLUS? For example, I'd like Makefile.PL
to bork a prereq if a system library is missing, or if there is no c
compiler.
ANOTHER DISCUSSION ANOTHER DAY:
why not Module::Build for xs? lots of reasons, starting with
Module::Build saying that xs support is alpha, and it is alpha - I'm
sure I couldn't have built Compress::Bzip2 with Module::Build the way I
wanted to, it's just lacking too many features.
-rob
--
Rob Janes
r w j a n e s a t r o g e r s . c o m
