If you're looking to conform to some standard way of doing this you may want to look at the FHS, which contains all the detail you could ever want on the subject.

Personally I'd say install your binaries in /usr/bin or /usr/local/bin, /bin is supposed to contain only essential binaries and should preferably not be cluttered by user applications (as a rule of thumb, /bin should contain only the binaries you need after a boot if you cannot mount anything except the root partition). perl isn't usually installed in /bin, and neither should your apps be.

As for the libraries, I usuall install somewhere in @INC. If your app will only be installed on a range of machines which belong to your organisation, then you could install in a custom directory and use lib, but I think it's too much of a bother to keep track of which apps need which library paths and only use this method when I'm testing a newer version of the libraries with an older one still installed. Also, installing libraries all over the filesystem can make it hard for someone else to maintain the system because they have to check all your custom paths as well as the usual ones for outdated library versions.

Another good thing to do is to convert your Perl tar.gz packages into the package format native to your platform( for example .rpm for Fedora) and install from there. This is trivially easy to do on .deb-based systems, due to the very useful dh-make-perl script, and I'd guess something similar is available for rpm as well (or you could always use dh-make-perl and then convert the resulting .deb into .rpm with alien). Sticking to the system packaging format makes it easier for an admin to know what version of what software is installed where, which application a particular file belongs to etc. It also simplifies installation and update for multiple machines.

It doesn't matter what your application is written in. C, Python, Perl, Bourne Shell or Intercal are just fine.

In *NIX you consider what it is written for. Chose /opt or more often /usr/local as bases, if the application is simple, just drop it there. If it needs lots of executables or lots of data, create another subdirectory there. That's all. On other platforms, there are other habits.

I'd expect others not to mix their modules with the system-wide Perl installation, unless they install directly from CPAN - or with the new perl's core =). But that's just my way of expecting it to be.

Cheers, Sören

If I was writing an application with perl where should I put the files?

I take it your Perl "application" is one or more Perl scripts, and a suite of modules. There are standard places where these go for installing as root (if you're not installing as root, this can be done - you set up your own custom directory tree with bin lib and man directories, and include lib and bin in PERL5LIB and PATH respectively).

The default place to install will be the same directory tree as where perl itself is located, usually /usr/bin/perl or /usr/local/bin/perl. If you are using a standard install (by root) you won't need to know exactly where modules go under /usr/lib or /usr/share, as this is taken care of for you.

Hope this helps

Can I get some thoughts on the matter?

If you're distributing Perl based applications PAR will be well worth looking at.