Re: State of the Art wrt XML/XSL.
On Sat, 15 Jul 2000 18:24:19 Joey Hess wrote:
> Fred Reimer wrote:
> > Well, I wouldn't use quite so strong words, but I don't understand
> > myself why Debian has to make custom deb packages for CPAN modules.
>
> There are several reasons. The most important two are:
>
> * everyone makes mistakes
> * TIMTOWTDI (really)
>
> Everyone makes mistakes -- so CPAN authors can make mistakes. Therefore,
> Debian has to have a way to correct those mistakes (and make mistakes of
> our own!). If we pulled directly from CPAN, we would have no way to
> insert fixes.
I'm not necessarily advocating pulling directly from CPAN, but rather
making it so that a Debian user CAN pull directly from CPAN, or upgrade
their Perl version, and STILL be able to use the system in a normal
fashion. I still don't see why Perl packages provided as binary DEB
files can't use the Config.pm file in my
/usr/local/lib/perl5/5.6.0/i686-linux directory to automatically figure
out where to install Perl modules.
>
> There Is More Than One Way To Do It -- not just in in perl coding, but in
> filesystem layout and system integration as well. Debian's filesystem
> layout for perl is not idential to the default perl layout. We did this
> for valid and good reasons, and perl demigods have looked at it and said
> it makes sense -- but modules have to be modified to fit in this layout.
> Debian's dependancy system is a superset of the dependancy information
> in CPAN, since it includes dependancies on C libraries and standalone
> programs. Therefore, we need to be able to manually add such dependancy
> information to perl module packages to ensure the high degree of
> integration that gives Debian its good name.
>
Yes, but has it been considered that people may want to upgrade to the
latest "stable" version of Perl for "valid and good reasons?" Heck, I'm
even running Woody and Perl 5.6.0 is not "officially" available as far
as I know. I understand all of the issues with dependancies, but if
someone want's to run a stable version of Perl on an unstable version of
Debian they should be able to do so without jumping through flaming
hoops. A little effort is reasonable, after all the person who wanted
to do so would have to be able to compile Perl themselves so requiring
experience is not unjustified, but making it damn near impossible points
to issue on how Perl is currently used in Debian, IMO.
> > 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'"
>
> And what do you do if your system is not on the net?
You use the Debian packages off the CD like you did to install the rest
of your distribution.
> Or if the perl module is an XS module and has to be compiled on the fly?
Then you compile it. Anyone downloading source code from the net would
be expected to be able to compile it, no?
> And you don't have space for a compiler or do not want it on this system
> for administrative reasons?
Then you compile it on another system.
> Or if the module on CPAN has been renamed since the last release of
> Debian, and the command fails?
You install the known version in the Debian pre or post scripts. Old
versions of modules are not immediately taken off of CPAN. I'd hope
that the Debian authors would be able to upgrade their packages before
it was taken off of CPAN, which would likely be years.
> Or if the module on CPAN has been upgraded since the last realse of
> Debian, and a newer version is retreived, which breaks other software on
> the Debian system?
You retrieve the specific module version that the Debian package was
written for.
Listen. Again, I'm not necessarily advocating that modules be compiled
on-the-fly when a Debian Perl module is selected for the "binary"
distributions of Debian. I'm sorry if I made it sound that way before.
Certainly a binary distribution should be made available. What I guess
I'm complaining about is that it seems too difficult to upgrade the
version of Perl in use on a Debian system. I should be able to upgrade
it on my own and get everything else from CPAN if I so choose. It seems
to me that I can't, because the Debian specific Perl code was not
written in the "standard" Perl fashion whereby you do a:
perl Makefile.PL
make
make test
make install
So obviously I'm having a communications problem explaining what I see
as an issue. If I could download all the source for Debian Perl
packages and >simply< reinstall them once Perl was upgraded then I
wouldn't see that as a problem. But, I don't think that's the case.
Since it looks like things are put into specific directories and do not
use the existing Perl configuration to find out where to put things, I
believe I, and anyone else, would have major problems attempting this.
So now I have to live with two separate versions of Perl on my system
and switch in between depending on what I want to do.
I don't know, maybe I'm uninformed. Educate me.
Fred Reimer
Reply to: