2008Q2 Grant Proposal - Extending BSDPAN

  • Name: Colin Smith
  • Title: Extending BSDPAN
  • Synopsis: Refactor the BSDPAN module into a generic and extensible solution for bridging CPAN with UNIX packaging systems.

Colin Smith

Extending BSDPAN

Refactor the BSDPAN module into a generic and extensible solution for bridging CPAN with UNIX packaging systems.

Benefits to the Perl Community:
The wealth of freely available code CPAN represents is one of the Perl language's greatest strengths. Tighter integration of this resource with a given operating system's native packaging system would give Perl a unique advantage over Ruby, Python, etc. while making it more accessible (and maintainable) to users.


  • refactored and fully-documented version of the BSDPAN module
  • dependency tracking across all operating systems
  • Module::Build support
  • OpenBSD support
  • more robust FreeBSD support (esp. rewrite of Packlist.pm)
  • time permitting, support for pkgsrc and at least one Linux package system
  • time permitting, explore options for BSDPAN integration without a customized Perl build (for existing systems)

Project Details:
BSDPAN was conceived (and written) as a glue module for interfacing CPAN module installation with the FreeBSD operating system's native package database. Blurring the distinction between CPAN and the FreeBSD `ports tree' in this fashion offers several advantages: modules honor environment variables such as $PREFIX automatically, and the user can query and manipulate them as they would any other software package.

I propose to expand BSDPAN into a more generic solution for bridging the gap between CPAN and the myriad of packaging systems in use today. This would include fleshing out BSDPAN's nearly nonexistent body of documentation, factoring out FreeBSD-specific code to a submodule accessed through a consistent interface, and adding support for

Project Schedule:
Expected timeline: Approximately three months, or the duration of my summer holiday, whichever comes first. Work will begin the week of May 26th (firm date to be decided upon receipt of finals schedule).

I've worked with Perl in some capacity for a little over eight months, and have dabbled in projects such as Catalyst and POE. I have significant prior experience in this problem domain, having the pfSense project's package system virtually from scratch several years ago. This system, written in PHP, ``wrapped'' FreeBSD package files for integration with a pfSense firewall's online administration interface, logging, remote administration tools, etc.

Amount Requested:
My work as funded by this grant would constitute at least some part of my summer employment, and as such I feel proposing an hourly wage rather than set milestones would be most prudent. Assuming an average of 15 hours of work per week at $15 per hour, two months of work could be funded for $1800.

Anton Berezin, BSDPAN's maintainer, was contacted over IRC and gave his consent for the project.


Seems like a strong proposal.

I have a concern with this proposal. Although it proposes to extend the packaging system, I don't see any real mention of which other operating systems, or how the people that operate distributions like Debian and so on would feel about being extended TO.

While FreeBSD does have by far the best package coverage at the present time, if this project isn't aiming for concrete results like "Make RedHat package availability as good as FreeBSD" but just for generalisation in general (so to speak) it's hard to put a value on it...


I understand your concert, but believe it stems from a misunderstanding of what I hope to achieve with this proposal (likely due to poor wording on my part).

There will be no obligation for any operating system 'vendor' to accept radical changes to their packaging infrastructure to use BSDPAN. The module simply wrests control of the CPAN installation process long enough to write a packing file, munge paths, and so forth such that the module being installed can be registered in the underlying system's database. If it helps, think of BSDPAN as the glue that will allow CPAN to be treated as just another package repository from the end-user's perspective.


This would definitely be useful. Currently dealing with the various packaging systems on all the different systems I end up doing work on is a bit of a pain. CPAN is the 'best' way of installing, but it frequently gets clobbered by package dependencies, causing modules to spontaneously change versions. Having CPAN co-operate better with the native packaging system would hopefully make this better.

I have said and written many times that IMHO there is a huge need to make lots of CPAN packages available in the various Linux and other distributions.
See the stats I have on

What I am missing from the proposal is, what Adam has also written, the clear understanding on how the goal of actually getting those CPAN distros into Fedora/RedHat, Debian/Ubunto etc. will be achived?

Have you talked to at least the Fedora and Debian Perl package maintainers?

Better yet, have you talked to the Perl maintainers of the commercial Linux distros?

how to reach them

Colin, could you add some comments about those issues to the proposal?

I'm underwhelmed by the proposal's attitude toward milestones. If the proposer wants an hourly paycheck, this is not the right venue. If the work is not done, the proposer does not deserve (full) pay.

That said, I think this type of work is very important. I worked on packaging Perl modules for Fink for a year, but burned out by the work involved. I tried to automate the process, but never was able to get a satisfactory solution. That was before META.yml really caught on, though, so the state of the art is different now.

I'd like to see a resubmission of this proposal (or another applicant) in the next grant cycle with serious milestones. If that happened, I would enthusiastically support the work.


I'll put out some feelers in that direction and let you know what I find out. Obviously the ideal would be to come upon a solution such that BSDPAN (or whatever it evolves into) could be used in concert with a vanilla Perl build, in which case it would only be a matter of making sure the package names generated by BSDPAN harmonized with those in the system's package repository.


The grant amount I arrived at was calculated based on what I could make serving food in the school cafeteria over the summer months, adjusted for the fact that if I were to spend that time writing Perl instead I would no longer qualify for discounted room and board. So yes, this money would in a sense represent my 'hourly paycheck' -- while this is work that greatly interests me and I would gladly do, I simply cannot perform it unsupported at this time.

I recognize the inscrutable list of milestones as a weakness of this proposal and do apologize for it. Several of those bullets (full dependency tracking, M::B support...) represent issues raised by Anton during our conversation, and I simply didn't have as much time as I would've liked to work them into a detailed schedule.


About TPF

The Perl Foundation - supporting the Perl community since 2000. Find out more at www.perlfoundation.org.

About this Entry

This page contains a single entry by Alberto Simões published on May 1, 2008 9:00 PM.

2008Q2 Grant Proposal - DBEditor was the previous entry in this blog.

2008Q2 Grant Proposal - Make localtime() and gmtime() Work Past 2038 is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.


OpenID accepted here Learn more about OpenID
Powered by Movable Type 6.2.2