[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: problems with the perl5 packages



On 23 Sep 1999, Michael Alan Dorman wrote:

> 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.

You know, Michael, I find your attitude towards me a bit annoying as well.

The fact that you did not understand the point I was trying to make in my
previous posting about perl and package managment is not too surprising.
Almost no one got my point, which was nothing to do with whether perl is a
good thing or not, but whether it was a "proper" tool for package
integration. I still think that an "extensible" language is _not_ a good
candidate for building integration tools, but that has nothing to do with
the current questions I have been asking.

Those points have/had nothing to do with my current questions, so why am I
a clueless idiot, and folks like Branden are just developers asking
questions? This last thread of mine has zero "perl bashing" content as far
as I can tell.

> 
> 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?
> 
Yes, and it even speaks to some of my confusion ;-)

So, pure perl modules only need depend upon perl5, while other packages
may need to specify a particular version of perl5.

So, why are there packages with depends lines that include both perl5 and
a particular version, like perl-5.005? Can I suppose that that package
misunderstands its dependencies?

Are there any circumstances where perl-5.004 is compatible with earlier
version like perl-4? I ask this because of mirror, which seems to work ok
with any of the perl version, even though the old version specifically
depends upon perl, and the new version specifically depends upon perl5. I
was mainly confused that none of the "new" versions provide perl. I can
only assume that this is because perl-5.004 is not backward compatible
with the previous version?

Thanks for the clarification,

Dwarf
--
_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- See www.linuxpress.com for more details  _-_-_-_-_-_-_-


Reply to: