Re: about requiring Perl 5.6 in Automake 1.9

[Bob Proulx]

Alexandre Duret-Lutz wrote:
> Perl 5.005_03 will be 5 years old next month, and supporting it
> is becoming painful.

I sympathize.  But actually the problem is not the age of the old
version of perl is but rather youth of the new version.  The new
version has not yet propagated yet.  But let me propose a way to use
the newer perl to make development easier and still make things work
for the stable production environment community.

> I'm considering dropping support for Perl 5.005 in the future
> Automake 1.9, and require at least Perl 5.6.  Perl 5.6 will be 4
> years old next month, so it does not sound like asking for the
> moon.
> 
> How many people would be annoyed by this?  Is there any reason
> why this would be a very bad idea?

If a newer automake requires /usr/bin/perl to be a newish version then
as Guido mentioned I think it would add to the problem of projects
seeing that as a hardship and not moving forward.  They would need to
upgrade /usr/bin/perl which tends to break things.  But if you avoid
/usr/bin/perl and instead use a configurable newer version from PATH
then a developer can install perl over on the side somewhere.  That
would mitigate the problem of using a newer perl on systems that don't
want to be upgraded at the system level.

Question:  How would you feel if the installed automake were to use
perl from PATH instead of the hardcoded in path?  Could this be made
available as an option?

  #!/usr/bin/env perl-5.6

Then it would be a simpler matter for a developer to install perl off
to the side of the system without any risk that anything on the system
depending upon the /usr/bin/perl will be affected.  It still means
that a developer would need to build a newer version of perl.  But
presumably if they are using automake then are a software developer
and can handle it.  (A false assumption in my personal experience.
But I will still go with it because they *should* be able to do so.)

> I know some people are still using 5.005_03.  We'd have never
> noticed the aforementioned breakages otherwise.  However I do
> not know why they do.  Is there any reason why upgrading to
> newer Perl versions would be undesirable?

I am one of the folks with a large number (>2000) systems all running
perl-5.005_02.  [That is right, _02 not _03.  But unless you count the
bug fixes there is little difference.  And then shortly _03 came out
and we were already stuck on the previous _02.]  Getting that upgrade
through was as painful as trying to get concensus among a large group
of people.  Ah, now I think you are seeing the problem.  Guido Draheim
posted with similar information and the culture of his environment
seemed similar to the culture of mine.

<whine>
The problem for us is SWIG (simplified wrapper interface generator).
If it were harder to create perl modules then this would not be a
problem. :-) Folks in the lab compile in random modules of their own
authorship into perl.  If perl is upgraded then all of those compiled
modules break.  Since these are all homegrown I have no way to
inventory them.  Some of the authors have moved on leaving binary only
code behind.  They are stashed here and there and everywhere.  And no
one will own up to having them until you actually have upgraded.  At
which time many things will be broken.  At which time the lab manager
will be over at my desk asking me why the project schedule is suddenly
going to slip.  This is not a happy time.  And since various projects
are always in different schedule phases there is never a time
available in which perl may be updated without affecting someone.  A
completely circular trap.
</whine>

There is a way to break the circular trap.  It is off topic for this
list.  But in summary '#!/usr/bin/perl' causes the problem.  If
instead '#!/usr/bin/env perl' were used then each project can pull
perl from their NFS tool server and move independently of each other.
I am pushing things this direction.  But I imagine others may be still
caught in the trap.  This is likely an issue more predominant in the
stable production environments typical of the commercial unix vendor.

Bob