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 ?
Alan
Reply to: