On Jun 19, 2005, at 4:53 PM, Rob Janes wrote:
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.
If you're replying to a previous statement, it'd be helpful if you
leave that part of the original mail in your
reply.. currently, i'm not sure what it is you're trying to reply *to*.
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 quite. Just like you do not first check if 'Foo::Bar' is installed,
and subsequently complaining about it, you
simply list is as a prereq of your module... This involves no
'checking' whatsoever, you just tell it what you need.
not to mention a being a great big tar pit.
The listing of the dependency is no tar pit. Having it installed is of
course another matter, but tha'ts not what you
wished to discuss -- you wanted a clear way to say 'hey, i can not
install myself with out X!'
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)
I'm not sure where this list came from. And quite a few of these items
seem oddly out of place.
Alien never says you have to follow these steps. In fact, it tells you
not to try and use a framework, but
just 'do what needs to be done' inside the standard 'perl Makefile.PL;
make; make test; make install' cycle.
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.
I have no idea what you're trying to say here...
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.
Actually, it's one package for every *non perl prereq* that you *as an
author* feel you *need to have resolved*
before progressing with the install. And if we look at whole of CPAN,
i'd be surprised if that's more than a few
dozen.
i'd like one package to deal with libraries, and the zlib Alien to
inherit from that.
Since a 'non perl prereq' could be anything, a framework is kinda hard.
As pointed out by the alien manifesto.
Not to mention that this would be a huge framework someone would have
to write, dealing with every conceivable
dependency on every conceivable OS.
Not viable in my opinion, but you're welcome to prove me wrong -- show
me code and i will believe you.
* 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.
That all depends on the implementation of alien module at hand.
* 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.
Since it's installed via perl, and every package should have a test
suite, this should not occur.
Of course, we can not stop people from releasing stupid or broken code.
However, that is not the fault of the
Alien concept, merely of it's users.
* seems focused on system libraries, not more general features, like c
compiler, linker, other commands.
There's nothing stopping you from making an Alien::CC package. You may
discuss the usefulness, but it's in
no way unsupported.
* 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.
I have no idea what this means.
* where do you specify the installation location? does the prefix
method set that or interogate it?
You dont need to, again, the Alien module should 'do what is needed'
and provide the perl module with the information
it requires to build.
* needs an api doc, not a manifesto.
Again, there *is* no API, as is VERY CLEARLY stated in the 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?
we're not trying to build a package manager in perl here... it feels to
me you're either grossly missing the point,
or are trying to solve every problem in the world at once. What is it
you want?
a) A way for modules to list non-perl-prereqs?
b) A way for modules to check for non-perl-prereqs?
c) A way for modules to satisfy non-perl-prereqs?
d) A way for every non-perl-prereq to be configured from perl and
interact safely with every environment?
e) A way for any package anywhere using perl to list any dependency
anywhere?
Please pick a topic, stick to the point and think it through.
* kind of heavy handed. suppose I don't want that prereq installed,
just cause I know better?
Then dont install it.
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.
Then dont install it. The same goes for an arbitary perl module that's
listed as a prereq. This seems a social
problem at best (one solved with education) and not one that undermines
a technology.
* 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?
.... you've lost me completely.
* 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.
Then you need to design your own OS/Package manager. I suggest dpkg,
it's very versatile.
But i'm not here to reinvent the wheel -- if you'd like to, by all
means. But this is not what alien is meant to do,
or what this discussion was supposed to be about.
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.
... and CPAN.pm i'd hope? It is still a supported module after all.
But please, come with a suggestion that would work, outline something
that does what you think is needed to be done.
Even better, show us code.
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.
again, lost me...
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?
You can't. EU::MM doesn't know how to.
Is there any way for my Makefile.PL to throw an error and diagnostic
of any sort to CPANPLUS?
You can't, EU::MM doesn't know how to.
For example, I'd like Makefile.PL to bork a prereq if a system library
is missing, or if there is no c compiler.
You can't, EU::MM doesn't know how to.
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.
Might be something you wish to address to the M::B list. As schwern
pointed out; if we dont believe in M::B one day
taking over from EU::MM, we might as well give up now.
I've tried to answer your points as they came by, but mostly, you've
left me confused; I dont know what you want,
what the real problem is you're facing or, if you've provided one, what
your proposed solution is.
Phrase us a clear question, please.
Until then I can only say; in the current setup of CPAN.pm, CPANPLUS,
EU::MM and Module::Build, using an Alien solution
will just DTRT, because you as an author have the power to make it DTRT.
For me, that's good enough.
--
Jos Boumans
"You know the world is going crazy, when
the best rapper is a white guy,
the best golfer is a black guy,
Switzerland wins the US Open sailing cup,
Belfast is considered the safest city for a Bush/Blair top,
France is accusing the US of arrogance
and germany doesn't want to go to war."
CPANPLUS http://cpanplus.sf.net
