Re: problems with the perl5 packages
Dale Scheetz <dwarf@polaris.net> writes:
> This brings up another issue. Both perl-5.004 and perl-5.005 provide
> perl5, but it was my understanding that these two versions were
> "substantially" different, at least during installation I got a long
> story about how I would need to convert databases to the new perl
> version.
That difference relates _exclusively_ to the change from using
berkeley db 1.85 to db 2.X, and the differences between those two
version are indeed substantial. Of course, this change could affect
any piece of software---sendmail, for intance, could have run into
this same problem, or postfix, or any number of other packages that
use berkeley db.
This is not, I repeat, NOT a perl issue, per se.
> It was my understanding that this was, in fact, the reason for
> constructing the package names so that they could both be installed
> at the same time, yet they both claim to be perl5!
You know, Dale, I find your attitude towards, and comments about, perl
quite annoying. Your understanding is deeply flawed, you apparently
haven't bothered to expend any actual effort to understand the state
of the language, yet you spent a week last month spewing FUD about
perl's instability as a language, and now you produce this petulant
complaint because reality doesn't confirm to your uninformed ideas of
the state of things.
Not one to holde a grudge, though, I will attempt to spell it out for
you as clearly as I know how. For more complete information, might I
commend you to the archives of the debian-perl mailing list, as well
as, perhaps, the perl documentation itself.
To begin from the beginning:
Perl is an extensible language.
There are two kinds of extensions to perl, those written exclusively
in perl code, and ones that also include dynamically loaded C code
(usually called XS code for various reasons).
Source code compatability for pure perl extensions has been excellent
throughout the development cycle of perl 5.X---in fact, going back to
perl4 and earlier.
For instance, the 'mirror' script that has been used all over the
internet for the last several years was actually written for perl4,
and, unless it's been changed in the last year, _still runs under
perl4_.
However, binary compatability is occasionally (reluctantly---and
usually reversibly, at the time you compile perl) broken when
needed---as was the case with perl 5.005's introductions of threads.
So, we arrive at a situation where perl5.004 and 5.004 are binary
incompatible for the purpose of loading modules containing XS code,
but are perfectly compatible for the purpose of loading pure
perl-coded modules.
So pure perl-coded modules are quite logically set to depend on perl5,
a virtual package that is provided by both interpreters, in order to
provide maximum utility for those who, perhaps for reasons of berkeley
db compatability, choose to continue running 5.004, while modules
including XS code are made dependent upon the particular version of
perl they were compiled against, in order to be sure to avoid any
binary incompatabilities.
Capice? Klar?
Mike.
Reply to: