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

Re: Feaping Creature-ism in core Debian Packages

> > Perl is unsuitable for specification.  There is no fixed grammar for
> > perl.
> And which languages *do* have "fixed grammars" in this sense?
> Consider that the Bourne shell has never had a published grammar that
> actually matched reality, yet it is still the basis for a multitude of
> installation scripts.

POSIX specifies a bourne shell syntax. The breakage from bash1 to bash2 
sums up why it is needed.

I can get a definition of
	sh (posix)
	C (ansi)
	C++ (ansi)
	Python (grammar available)

here is a simple question - how would you write a 100% perl compatible 
interpreter. What defines perl.

Its really bad for a script language because the breakage is run time.
Compile time breakage is a nuisance, runtime breakage hits users.

> > It sucks but its reality.  Majordomo broke on 3 out of 4 "minor"
> > revision updates to perl I did.
> I'd like specifics on this.  However, one recent Majordomo breakage
> was just a Perl bug, not a spec change, and it was fixed immediately;
> and another Majordomo breakage was actually a Majordomo bug (failure
> to follow the documentation).

Ok. This was a random majordomo through Red Hat 4.2 -> Red Hat 6.0

> > The perl community informs me that there is no perl grammar. They
> > don't themselves know what is and isnt perl except by feeding it
> > through interpreter of the week.
> This is gratuitous hyperbole.

Ok where do I find the definition. The problem with a standard is it needs
to reference a definition. Something has to say what is and isnt valid. Where
do I get a program other than the perl interpreter which when fed perl
says "yes" or "no" to it being valid (not neccessarily runtime correct) perl.

> > perl community don't back fix old perl.
> THIS is a vile lie.

Ok I was told that old releases where not maintained - eg perl4. How far
back does the maintenance go (bearing in mind obviously that there has to be
a 'you want it fixed you pay' between perl people and vendors assumed here 
as far as the LSB goes) 

> I am personally responsible for continuing the maintenance of Perl 5.4
> and 5.5 (recently taken over from Graham Barr), and I (and Graham)
> take security issues VERY seriously.  I patched a suid security
> problem in 5.3 when 5.4 was almost ready.  And I released a patch to
> 5.4 within the last few months, even though 5.5 is the current version
> and 5.6 is nearly ready.

So a standard that explicitly required say Perl 5.5 would be long term
acceptable and maintainable ? Thats obviously less desireable than a definition
but it does solve the fundamental short term problem which is ensuring
that "/usr/bin/perl" does the same thing on every distributions Linux box.

How would that look 3 years on as a decision ?


Reply to: