FAQ

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
one.

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.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 10 of 27 | next ›
Discussion Overview
groupmodule-build @
categoriesperl
postedDec 15, '12 at 10:59p
activeDec 31, '12 at 6:39p
posts27
users11
websitecpan.org...

People

Translate

site design / logo © 2017 Grokbase