Re: State of the Art wrt XML/XSL.
Fred Reimer <fwr@ga.prestige.net> writes:
> I don't understand myself why Debian has to make custom deb packages
> for CPAN modules.
Because anything else is *impossible* to reliably integrate, debug or
otherwise claim to be demonstrably working in what is suppsed to be a
internally consistent, largely plug-and-play distribution.
Please note: there is _nothing_ that prevents people from installing
perl-5.6 on their Debian boxes and using it. I think you'll find that
a number of prominent Perl developers---Chip Salzenberg and Graham
Barr, perhaps Andy Dougherty and others that don't come to mind right
now---are able to use Debian as their platform for development with no
problems.
However, and here's the thing that I wish Michael Koehne would take
some time to understand: Debian is a distribution. The whole point is
that we present a pre-packaged, working set of packages that are all
intended to function together. Sure, you can add things on---hell,
you can use CPAN with our perl-5.005 packages, if you want, you don't
_have_ to use debs of other-than-core modules at all---but replacing a
core tool upon which a large part of the distrbution depends with an
arbitrary hunk of user-compiled code is a guaranteed way to cuase
ourselves no end of bug reports about which we will be able to do
*absolutely nothing*. Hell, Michael himself admitted that Perl 5.6.0
wasn't stable enough to use as the default perl on Debian in a message
to this list.[1]
> Wouldn't it be workable to create deb "packages" that were more like
> installation helper scripts instead of the binaries themselves? So
> you select a package and when it was installed your system would run
> something like "perl -MCPAN -e 'install XML::XPath'"
Taken to its logical absurdity, why are you using a distribution
anyway? Why don't you just self-compile everything using little shell
scripts that download them things for you. I used to maintain Solaris
boxes like that.
The answer is "it's not appropriate for a distribution". It means you
have to have a whole host of tools you might not otherwise have, just
to install Digest::MD5 or HTML::Parser, and heaven help you if you
have to do some of it on the old 386 that's sitting in the corner
being used as a RAS server.
But, as I said before, if you want to go this route, fine, use CPAN,
not our pre-compiled packages. It'll work.
> Part of the strength of Perl is that you can relatively easily
> install and remove packages. Mixing this ability with binary
> packages, in either a deb or rpm type system, just makes it harder
> to maintain two different "systems."
Learn to create the debs yourself, then. It's not hard---in fact, you
can do most of them using a template where only about five lines
change, and it only takes about five minutes a shot.
Of course, some would suggest that the nigh-mechanical nature of the
process suggests it should be automated,---to them I say that I did a
totally clean install 5.005 on a Solaris box, and when I installed
Bundle::CPAN using CPAN (my first action) the perl installation
promptly rendered itself unusable because certain things didn't build
because the Solaris box wasn't set up for it, and it didn't detect
failures adequately, etc. I reinstalled perl and decided to deal with
dependencies and such by hand, installing each module individually.
That has _never_ happened on my Debian box, in part because _there's a
human in the loop_. Anyone who doesn't understand the value of that
in keeping a working system needs their head examined.
Mike.
1. www.debian.org/Lists-Archives/debian-perl-0005/msg00001.html
Reply to: