All the Perl that's Practical to Extract and Report

Imager file format modules

tonyc on 2009-09-21T03:25:04

I'm considering splitting out Imager's file support for those file types that require external libraries, in particular:

  • GIF
  • TIFF
  • JPEG
  • PNG

Possibly also the font file handlers:

  • Freetype 1.x
  • Freetype 2.x
  • T1Lib
  • Win32

Unlike the current Imager package these would fail to install unless the appropriate library could be found (or built), so your code could depend on Imager::File::GIF and be sure that GIF support was available, which isn't currently the case.

I'd produce file format distributions such as Imager-File-GIF at least six months before removing them from Imager itself. Installing such distributions would add (for example) GIF support to Imager if it wasn't already present, or be ignored if it was.

I'd also release Task::Imager which would depend on Imager and each of the file format support distributions needed to match the Imager <= 0.69 world, though perhaps excluding T1Lib and Freetype 2.x

This allows:

  • just depend on Imager::Task to get the same file formats you get now (possibly some more)
  • depend on Imager::File::Foo to get the format you want and be sure they're present

Reactions?

(I suspect this is going to be more painful for packagers than anyone else.)

Speaking as someone that uses Imager at work

Alias on 2009-09-21T03:54:28

It would make our life simpler, we've been caught out in the past because we installed Imager but didn't actually validate we could produce an image of a particular type when the code actually ran.

Re:Speaking as someone that uses Imager at work

barbie on 2009-09-21T08:26:59

Likewise, I've been caught out by missing libraries. Not a big problem for me, but providing specific plugins would make it a little easier to confirm what support is actually available.

Good idea!

jj on 2009-09-21T10:20:45

It would be great if the Imager::File::* modules could build a private copy of the required libraries in the module directory, similar to Alien::Zlib. This would really simplify installation, especially for users without root access.

Re:Good idea!

tonyc on 2009-09-21T12:40:56

As a mechanism, I'd probably have it depend on Alien::libgif (for example) which could then could either detect or build libgif.

My main problem with the typical Alien:: module is that it installs the module from source rather than as a native package for the current system, which means if the vendor releases any security updates Imager (or whatever) will still be using vulnerable libraries.

One option could be to have Alien::libgif realize it was on a Debian system and then depend on say Alien::Debian::libgif which apt-get installs libgif-dev, or on Redhat, Alien::Redhat::libgif which yum installs giflib-devel

Of course, if it detected libgif already installed it would just return that.

If the system didn't have a known package manager (or libgif package) it could then install from source, possibly as Alien::Source::libgif.

Of course, this could be overcomplex, but I really don't want to add extra insecure software to user's machines.

Re:Good idea!

Alias on 2009-09-21T17:12:06

The purpose of Alien:: is to not necessarily to install it from source.

It's job is to ENSURE that it is on the system, and provide access to information about the installed version.

You can quite reasonably have the regular Alien::libgif install from Debian if you want, or use the existing installed one, as long as it still compiles as a last resort, and it returns the information about the installed module.