2012Q1 Grant Proposal: Easy installation of non-CPAN dependencies

Category: Grants , Perl Foundation

Comments (8)


just having a perl interface to yum would be excellent. but it only has an api via python, no c based libraries (making Yum::XS possible) or anything else sensible. you may have to wrap the thing with expect... :(

why redhat doesnt just give up on rpms is beyond me...


I've been using Perl for years but always dreaded installing certain modules because of the problems with external libraries, and (to me) the frustrating error messages - dylib this and header that. I often just gave up and it is only now I realize how much I was missing. So I think a project like this is very good, especially if the needs of inexperienced users are taken into account (e.g. error messages that point to places where you might find help - and I don't mean man pages).


Hey, how this grant would relate to the other Alien:: grant that is also waiting approval?


Relationship between our projects is similar to relation between installing software from source and from pre-built packages. Both ways have advantages and disadvantages. Of course, installation from source with Alien::Base::ModuleBuild means that you will get newest version. Also you will be able to compile with other parameters that your vendor did. But complexity of maintaining Alien:: distribution (for ex. author needs to apply patches for every version of OS/distribution that does not compile out of box, similarly to OS vendors) means that most CPAN authors will not create them or will not supply patches. User will also be required to monitor dependency for vulnerabilities. And of course, it will require compiler/linker installed (some web hosting servers do not have gcc, but are willing to install CPAN modules) and all libraries that this library depends on (building Alien packages for them would be too complex), including headers. Most sysadmins prefer to have non-CPAN libraries to be installed from vendor packages, and in future CPAN::non will be able to simplify building vendor packages from CPAN modules.
IMHO, both ways are useful. As Joel Berger writes, Alien::Base::ModuleBuild could even use this project. Or vice versa :).


Most sysadmins prefer to have non-CPAN libraries to be installed from vendor packages, and in future CPAN::non will be able to simplify building vendor packages from CPAN modules.


This is what lead me to my core concept that all installations should target File::ShareDir; this makes library installations essentially indistinguishable from CPAN installations.

You are correct that complex libraries with deep dependencies chains or OS specific patches would be harder. It is for this reason that I will have a handler for downloading specifically pre-built binary packages (built for the specific Alien:: module).

May I ask, what will be the fallback if CPAN::non doesn't support the local package manager?


I'm going to say the same thing for all the grant requests this round ...

As a general rule, I think grants should be used to fund development on projects that are already established.

Speculative projects are just that, speculative. Even if the grant is completed, it's really hard to know whether the resulting work will be useful to anyone.

When funding work on an existing project, we already have some idea of whether or not that project has traction in the wider Perl community.


Most OS’es would be supported, support of yum and apt means 90-95% of Linux installations. In future I plan to add FreeBSD, possibly Mandriva/Mageia, SUSE, Solaris and Cygwin. For Windows I planned to use same method as you plan: installing prebuilt archives. If OS/distribution is unsupported, error message would be printed with general instructions how to find out which package to install. Or use Alien::Base::ModuleBuild to see if it will be able to install :).


What I would really love is a good interface to apt. I have tried to write a script to run immediately after installing a fresh Ubuntu. I finally gave up because I couldn't get useful information about what was installed, installable, which repositories were available, etc etc. That would be a great thing. Once that was running, I would be happy to incorporate it into Alien::Base or support its existence in some other installer mechanism.


Sign in to add comment