Perl upgrade breaks gnome system tools

[Tim Heaney]

Binary package hint: gnome-system-tools

I built Perl 5.10 from source and installed it in /usr/local/bin/perl. The original Perl is still in /usr/bin/perl.

  tim@mrbun:~$ /usr/bin/perl -v | grep "This is perl"
  This is perl, v5.8.8 built for i486-linux-gnu-thread-multi

  tim@mrbun:~$ /usr/local/bin/perl -v | grep "This is perl"
  This is perl, v5.10.0 built for i686-linux

This broke system tools such as System->Administration->Time and Date, which failed with

  The configuration could not be loaded
  You are not allowed to access the system configuration.

this message. I believe the culprit was actually

  /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl

which has a shebang line of

  #!/usr/bin/env perl

and, of course, that's now finding the wrong version of Perl

  tim@mrbun:~$ /usr/bin/env perl -v | grep "This is perl"
  This is perl, v5.10.0 built for i686-linux

I think it's a mistake to use env this way in system scripts. Changing it to /usr/bin/perl fixed everything.

  tim@mrbun:~$ head -1 /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl
  #!/usr/bin/perl

ProblemType: Bug
Architecture: i386
Date: Thu Mar 6 08:59:22 2008
DistroRelease: Ubuntu 7.10
NonfreeKernelModules: nvidia
Package: gnome-system-tools 2.20.0-0ubuntu2
PackageArchitecture: i386
SourcePackage: gnome-system-tools
Uname: Linux mrbun 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux

[Sebastien Bacher (seb128)]

Thank you for your bug report

[James Westby (james-w)]

Hi,

This was fixed in 2.6.0-0ubuntu2, but a typo meant that it wasn't
closed at the time.

Thanks,

James

[Emilio Pozuelo Monfort (pochu)]

Created an attachment (id=17579)
Use the system perl

From https://bugs.launchpad.net/bugs/199134

Some s-t-b scripts don't use the system perl, which could lead to a broken gnome-system-tools if the user installs a broken perl.

The attached patch fixes this by setting the shebang to /usr/bin/perl

[Milan Bouchet-Valat (nalimilan)]

Not sure that's the perfect fix. What if we want to use a custom version of perl, say using jhbuild? Shouldn't 'env perl' return the default perl interpreter, and not some random one? Just trying to work things out.

[Emilio Pozuelo Monfort (pochu)]

I think the common practice is to use the system one:

emilio@saturno:/usr/bin$ grep -E "\#\! ?/usr/bin/env perl" * | wc -l
12
emilio@saturno:/usr/bin$ grep -E "\#\! ?/usr/bin/perl" * | wc -l
350
emilio@saturno:/usr/bin$

[Milan Bouchet-Valat (nalimilan)]

Well, with such statistics, I'd need strong arguments, which I don't really have. ;-)

It just feels strange to me that you don't have any way to use a custom perl for a given program if you want, just like you build it against a custom library. But I don't think anybody will want to do that with the stb, so better prevent breaking them.

Pushed as 2916c228e818dca562a963958f3f5db40d579018 (I've fixed a few more files that still used /usr/bin/env). Thanks for that patch!