On 2012.12.16 1:10 PM, Leon Timmermans wrote: > On Sun, Dec 16, 2012 at 6:34 PM, Johan Vromans <jvrom...@squirrel.nl> 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.
