#!/usr/bin/env != /usr/bin/perl

I just say one thing … I hate irrelevant policies. Now I have to either patch 59 files in TeX Live, or write a script that goes through a few Gb of data to search like lintian for these kind of things, and replace it automatically on build time.

Now what was the argumentation for this change on the Debian Perl list:

No, for perl programs shipped by Debian, that can only be expected to work reliably if invoked with /usr/bin/perl – any other perl that happens to be in a user’s $PATH might not have the correct modules installed, or might have other behavioural differences that break things. Note that this change is about fixing a long-standing inconsistency between the main part of policy and the perl sub-policy; this requirement has been a must in the perl policy since 2001.

Speaking to your arguments, the user is of course free to use a different perl for applications installed locally, but this should not be the case for packages in Debian.

I can not disagree more. I consider it our (= Debian Developer) job to package stuff, but not to hold the sysadmin hand if he wants to shoot himself. I consider it a valid use case to replace/override a Perl installation by prepending it to the PATH (think testing of new Perl or Perl development). In this case, I expect Perl scripts to use the Perl *I* as sysadmin provided. In this case it is the obligation to ensure proper availability of modules and support files.

Doing this kind of policing is not helpful at all, thus I filed a bug against debian-policy to get this requirement removed.

What a waste of time. Thanks a lot for a useless addition to the Policy!