see below.
Jos I. Boumans wrote:
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*.
seemed to be getting a bit long, so i chopped it.
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.
i thought i was agreeing with you in principle, but prioritizing the
prereg check first, then install stuff later, separately.
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!'
the tar pit is the installing of system software, not the checking for
system software. yes, i want a clear way to say "hey, ... X". oh, and
to report on it to the installer, not the developer, so the installer
can choose to do something about it.
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.
out of place? well, anyways, i made up the list. which is not to say
that i think it's wrong ...
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...
on the other hand, you're clear as a blue sky. :-(
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 think we're on different sides of the elephant. i'd be surprised if
it was less than 1,000.
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.
no, no - i'm agreeing with you there, it's a big tar pit and i don't
want to write perl code to do it, at least not as a standalone effort.
* 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.
I thought it depended on how cpanplus dealt with it. isn't cpanplus the
one that detects that alien is needed using standard perl module
lookups? if alien is already there, cpanplus doesn't, and shouldn't,
try to see if the alien feature is functional.
* 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.
No, i don't think it's a broken code situation, the situation i'm
refering to is a valid choice for the package installer, not an error in
the package. 64bit vs 32bit is a reasonable choice, either one should
be allowed, if the machine architecture allows it. however, the perl
installation can only be one or the other not both. for a system
package installation targetted for perl usage, the only choice is
whatever perl is, there is no other workable option. Even if the Alien
package detected the other installation of it's feature, which is
difficult to do for many reasons mostly having to do with the system not
the package, installation of a perl varient is something that should be
carefully considered.
* 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.
I think Alien::GCC that installs the gnu c compiler on my machine would
be great. Since the gnu c project is heavily committed to autoconf,
etc, this would only be viable as some kind of sister project of gnu c.
Alien::VisualCdotNet? Maybe Alien::Borg is a better name. Installing a
c compiler is not something done lightly. There are lots of choices and
the wrong choice can damage your system - oops, my kernel doesn't build
anymore, darn! I don't think something like this should just slide into
home as a prereq for base64 encoding.
* 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.
i get the groggy feeling that the module::build thread needs some input
from the xs crowd.
* 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.
i read a spec for the god program, that alledgedly ran on an ibm360 once
upon a time. no parameters, files or arguments were necessary, as it
would know what to do and what to do it to once it started. there is no
one choice for installation location. even perl has more than one
choice, system, vendor or site?
* needs an api doc, not a manifesto.
Again, there *is* no API, as is VERY CLEARLY stated in the manifesto.
i didn't mean to come across as if i had invented the idea. i was
listing all the problems. lack of an api is one of the problems.
* 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.
the topic here is problems with Alien. i'm on this one mostly cause
Alien seems to be coming up as a solution for the prereq problem. The
alien manifesto says it's for satisfying prereqs, not so much checking
them. Anyways, I don't think Alien is an answer for checking or for
satisfying. So, here I'm responding to Alien in general, not
specifically for the prereq issue.
Of your points there, I think a and b are linked and are what I'm
looking for. c, d and e are what i am trying to dispense with.
* 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.
yes but my point is that the thing looks like a regular cpan module.
cpanplus comes up and says here are the prereqs that failed, lists them,
and i usually just glance at it and say yes, go ahead install the lot
cause it's only perl. My point is that this Alien thing isn't just
perl, but nothing will jump out and say that there is this side effect
of installing the Alien.
* 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.
this hasn't been discussed before wrt Alien?
* 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.
dpkg installs binaries, it does not build from source. a package
builder is one that compiles the package. a package manager is one that
manages binary packages. i mentioned gentoo earlier because it is a
distribution of linux which unlike all the others, builds itself from
the source.
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.
The alien manifesto simplifies things a lot, but if you actually
consider what they are talking about, yes, they are reinventing the wheel.
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.
imacat has summarized on this thread various tactics xs modules,
including mine, have used to deal with system dependencies. I'm
considering some code, but for it to work I need a better answer from
you than you've given below.
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...
well ... i'm basically saying keep it simple, don't make it complicated
... like gnu configure.
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.
but you do. let's say for the moment i am willing to override parts of
eu::mm. got my sledge hammer out, how do i make cpanplus know what i
want it to know?
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.
hey, i like the modularity of m::b. i want it to work. i looked very
hard at it but at the end of the day, couldn't use it. the problem is
that h2xs uses eu::mm, and that just makes it too damn easy to start
with eu::mm. then when the xs guy looks over to m::b for the stuff he's
used to, it's not there. to make it go, the xs folk gotta throw some
code at m::b. i'd suggest a round of spec talk, and dose of inheritance
from m::b. maybe a bof at the yapc::na, or a 12 step group for the
makefile philes.
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.
my immediate problem is that Compress::Bzip2 build is failing, due to
missing compiler. the error is not being categorized imho properly. i
don't want to see every xs author having to write a check for the c
compiler, myself included, i think that's stupid. i'd like to see it
part of the prereq analysis. i'd like to see the Makefile.PL throw a
distinguished error to cpan or cpanplus so that the error would not be
misclassified. i have become aware of a reporting stream that appears
to come from cpanplus and maybe cpan. i have not used cpanplus to
install compress::Bzip2, so i have no idea what reports come out from
that process. An NA error has been mentioned. I have no idea how to
throw an NA error.
with regards to the bzlib library, is it there or is it not issue, i
have taken care of that. i am not happy that every xs author, myself
included, must rewrite the wheel here. i think there is a better way to
do it. i think that if i had known how to throw an prereq error to
cpanplus or the testers, i might not have put the bzlib into
Compress::Bzip2. maybe. i do like that it's available on more
machines now with the static bzlib imbedded.
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.
Can we just put the Aliens in the X::Files?
ok, ok, i tried to spec out a framework for system prereqs. i think it
rocks, it's in an earlier posting to this thread. it's part of an
answer. the questions i had are above. they were pretty clear, and you
answered them, although not with the answer i wanted. please have a
look at the questions again, maybe something else will come to you.
i've added some questions above, what are the error types and how do you
throw them.
i hope that settles the dust.
--
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
--
Rob Janes
r w j a n e s a t r o g e r s . c o m
