PAR looks interesting -- thanks for the suggestion! I'm a little put off by the apparent complexity of it, though. Maybe I'll give it a shot and see how far I get.

Hmm...interesting idea. It would be sort of like distributing a C program as a statically linked binary. There are some practical reasons why that might not work well, however. For one thing, the Perl/Tk module is really huge, and a modem user who already has it installed probably doesn't want to have to download it again. It would be sort of like telling everyone who downloads a Java app that they need to download Swing along with it, even if they already have Swing installed :-)

It may be large, but it's the best chance of getting a workable solution. I suppose you could host the modules on your website in the various forms needed then have your install script hit your website, that way you still have complete control but the download is slightly smaller for some people. But of course that solution still breaks some of the time and is pretty stupid.

People want a solution that Just Works. I seriously doubt people will care about the extra 10 minutes of downloading required to get these modules. If you really cared about those few who would care, simply post two versions "version 1 with all modules needed" "version 2 with install script" or something.

For one thing, the Perl/Tk module is really huge, and a modem user who already has it installed probably doesn't want to have to download it again. It would be sort of like telling everyone who downloads a Java app that they need to download Swing along with it, even if they already have Swing installed :-)

So you would only provide the bundles and nothing else? In that case it wouldn't be practical for everybody.

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"

I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).

** The third rule of perl club is a statement of fact: pod is sexy.

Try e-mailing the people who have made the rpms and debs, offer to host their packaging of your program if they keep it updated. Toss their package up and thank them on your downloads page, and you've just made an Internet friend for life (in addition to making your software easily accessible to more users).

You might be surprised how enthusiastic of a response you get from people, especially because they're obviously interested in your software. They also may have ideas on how to incorporate automatic building of rpm and deb files into your normal build process.

One more thing: I'd definitely learn how to use PAR to package the CPAN modules for your application, it will improve your Perl kung-fu greatly. :)

Try e-mailing the people who have made the rpms and debs, offer to host their packaging of your program if they keep it updated.
Yeah, that's probably a very sensible idea.

One more thing: I'd definitely learn how to use PAR to package the CPAN modules for your application, it will improve your Perl kung-fu greatly.
PAR looks cool, but it does look like it would require taking my perl-fu to the next level :-) I wonder if Perl 6 and Parrot will simplify this process at all. Even if PAR works great, it strikes me as kind of a bolted-on mechanism for something that might be better supported within the language itself. IIRC, Perl 6 will eliminate the problems with having to recompile XS when you upgrade perl; that will really be nice.

I am used to installing programs by source, which is quite simple, and usually goes like this: download, extract tarball, read README, run configure, make, make test (or make check etc), make install (as root). The good thing with CPAN is, that the same technique works with CPAN modules, so I didn't have to learn anything new to install a CPAN module.

I don't quite know how installing your software works. If it works the same way, that is, it is a source tarball, then whoever installs the software must know this process already, so I recommend using the same way (no need to install the CPAN module). This may still be difficult to do for someone who only installs from debs/rpms so don't know how to install a program from source.

You could also make a tarball of your program that has the CPAN modules inside it and configures+makes them automatically when you install the program itself (but if the modules are large relatively to your program, you should give a source tarball without the modules too.).

Yeah, I wouldn't consider it an especially difficult piece of software to install, for somebody who is familiar with installing source tarballs. It's just that I've tried to insulate them from that a little, so that all they really have to do is 'make depend ; make install', and all the dependencies will just automagically get satisfied.

I talked again to the particular person who e-mailed me earlier today, and he's using yum (an rpm-based system) on Whitebox Linux (a fork of Red Hat), and I guess is used to installing everything from binary rpms. I don't know why he didn't have CPAN.pm installed; maybe I'm worrying needlessly based on something borked in this particular guy's Perl installation.

It's a little spooky distributing open-source software, because you can't tell whether the people who e-mail with problems are 1% of your users or 99% :-)

For instance, I got an e-mail today from a Linux user (he didn't specify what distribution) who tried running the installer script, and had a problem because he'd never installed CPAN.pm.

It's nice that CPAN is cross-platform, but getting CPAN set up in the first place is nontrivial for many users. (The number of configuration questions it asks is just astounding, and it's not necessarily true that you can give the default answer to every single one.)

My software is open-source, so I have no way of knowing what percentage of users are actually having problems, but I'd like to make it easier for them.

I use FreeBSD myself, and it's not practical for me to create and test separate versions for every Linux distribution.

Abigail

Uhm, really? CPAN.pm comes with perl.

The Linux user most likely meant that he had never configured CPAN, highlighting the inexperience of some users. A previously unmentioned option for getting around this would be to link to a tutorial on configuring/using CPAN. However, some users simply don't want to configure CPAN, no matter that it should take any person with half a brain about 5 minutes to do. If you were to require that users correctly configure CPAN in order to use your program, you would be losing part of your potential user base. Shielding your users from advanced configuration issues can be a slippery slope, but I think that in this case it makes sense. The target audience for a Perl/Tk grading program is not necessarily interested in learning how to configure CPAN, and providing them with a very easy means of installing and using your program is a good thing.

There are definitely lots of ways to do this, such as PAR or cpan2rpm, and I think that making installation easy on your users is part of marketing your application, something that bcrowell2 seems to be interested in.

Also, I think PAR is very cool. :D