Jonathan Yu <jonathan.i...@gmail.com> writes: > On Thu, Jul 2, 2009 at 5:26 PM, Russ Allbery<r...@debian.org> wrote:
>> I would really prefer that people not start writing maintainer >> scripts in Perl as a matter of course. Perl is harder to analyze for >> programs like lintian than shell scripts (which are already hard >> enough). > I agree that all too often many build systems are sort of centered > around Perl, and that can be a bad thing, in terms of maintainability. > On the other hand I don't think Perl is always unmaintainable -- it > depends on the programmer. Just to clarify, it's really not maintainability that I'm concerned about. It's automated analysis. Take a look at checks/scripts, checks/menus, checks/debconf, and checks/shared-libs in Lintian, among others. Currently, we mostly just bail if Perl is used for maintainer scripts since it's much more difficult to do the sort of checks that Lintian is doing against Perl scripts. There are more ways of expressing conditionals that are widely used, there's additional punctuation and potential line wrapping in system() calls, and all sorts of other issues. Perl is a problem specifically because it's a richer language. Any other richer language would also be a problem. For better or for ill, Bourne shell is fairly straightforward, and while it has some odd corners, it doesn't have that many syntactic quirks or that many different ways of doing the same thing. It also helps considerably that the way to run an external program (which is much of what Lintian checks) is to just run it, without additional syntax or function calls. Note also that if you use Perl to write maintainer scripts but you're using debhelper, you have to use somewhat strange workarounds to get the debhelper fragments to be invoked, and those too are hard to analyze. I've been quixotically proposing for several years that the ideal solution would be to write a new interpreter specifically for maintainer scripts that had a simple syntax and directly supported the 20-30 most common things that one needs to do in a Debian maintainer script. One could start with anything that debhelper adds to maintainer scripts and then add diversions, alternatives, deleting files and directories, and maybe two or three other things. Packages that need something more complicated could fall back to shell or Perl as they do today, but I suspect that writing an interpreter that could handle the maintainer scripts for 90% of the packages in Debian would not be particularly difficult, and it would also potentially hide a lot of complexity and would be an opportunity to get the behavior right in all the tricky error rollback cases. Of course, I have no time to do the work. :/ -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org