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
