develooper Front page | | Postings from December 2012

Re: How To Build A Perl Package Database

Thread Previous | Thread Next
Michael G Schwern
December 17, 2012 00:43
Re: How To Build A Perl Package Database
Message ID:
On 2012.12.16 1:10 PM, Leon Timmermans wrote:
> On Sun, Dec 16, 2012 at 6:34 PM, Johan Vromans <> wrote:
>> Debian, and most other systems have decent package- and install
>> managers. *They* maintain the database with installed distributions,
>> releases and files. The only good approach for us is to play with them.
>> So, an enhanced META.yaml or whatsoever may be a good idea, but *only*
>> to generate a deb control file, or rpm spec file, or innosetup file and
>> so on.
>> It is no longer neccessary to handle everything ourselves. We're not
>> alone anymore.
> There are many ways to deploy stuff, not everyone uses rpm/deb, there
> are good reasons not to do so: for starters it assumes you have root
> privileges.

I agree with Johan that there are better ways to do this.  I also agree with
Leon that they are not available to all users and operating systems.

I would much, much rather use an existing, reliable system than build our own.
 Really really really!  But Perl is a cross platform, cross environment
language.  Not all the environments we work with have good package managers.
Off the top of my head: Windows, a huge, hidden number of our users, has
nothing usable and the Solaris package manger is a joke.  Not all users in
those environments have access to those package managers.  Not everybody wants
to use them to manage Perl.  For example, cpan2rpm is a commendable effort but
also a nightmare.

In addition, there are some people who live on one OS and are happy and
comfortable with how that OS does things.  And there are people who happily
jump from OS to OS and want to do things the Perl way.  Its nice to be able to
sit down on any given machine, grab cpanm, perlbrew and local::lib and get
everything running smoothly.

OS packages are oriented towards one install per machine.  Perl is per project
and/or per user.  Furthermore, Perl is part of the operating system.  Making
the needs of your project not conflict with the needs of the operating system
is tricky.  There are ways to shoehorn OS packages to do these things, but it
doesn't work well, many admins don't know how to do that, and its different
from OS to OS.

If none of that convinces you, I'll say this: we've been advancing the "build
OS packages" route for years now and its never really worked.  There's tons of
Perl shops out there with tangled, messed up Perl/CPAN installations who find
it difficult to upgrade in part because they can't replicate their
installation.  My current client is one of them.  My best practice for dealing
with big Perl installs is to make one giant OS package of a non-system perl
and all the necessary CPAN modules rather than making individual CPAN module
packages and their interdependencies come out right.  This is kind of gross,
but its manageable.

Most shops that make it work have a Perl expert on hand.  They should not need

This is in no way in conflict with advancing cpan2package tools.  If done
right the package database will make packaging Perl modules *easier*.  Those
same hooks and APIs I talked about to allow for enhanced package database
functionality could also be used by OS build systems.  The needs of the
package database will force modules to become more normalized and provide more
and better meta data.  At worst, it won't make it any more difficult.

Open Source is not a zero sum game.

The interface should be as clean as newly fallen snow and its behavior
as explicit as Japanese eel porn.

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About