Dave Howorth wrote:
> Drew Crampsie - Software Developer wrote:
>
>> using CPAN to install perl modules in debian is not a good idea! a
>> later .deb install of a module could clobber something.
>
>
> This is not the case, AFAIK. CPAN installs in a path closer to the
> front of @INC than Debian packages, so nothing gets clobbered and
> CPAN-installed packages are used by default.
I don't really see this as a good thing. I'd prefer to always use a
package installed by debian over a CPAN one. Having a CPAN build shadow
my debian install of the same library is not what i want to happen. This
is, of course, just preference.. but i wouldn't want things that i know
are working to break because a new version of the module is shadowing my
old version. and the dependency hell that can result scares me. i
started using debian simply because it handled dependencies better then
any other option at the time.
Besides that, there is a number of reasons why i prefer dh-make-perl:
-Removing a module becomes a lot easier. this helps quite a bit when
testing a new version . i simply create a .deb, remove the old package,
and install the new one. if it breaks my app, i can revert quite simply.
-Installing to staging or production is a simple matter of using
dpkg to install all my tested versions of the modules, rather than use
cpan, or a big tarball or whatever. I find this to be a reliable
method. A simple shell script can install my entire application.
-It works for my own modules as well.. i create a .debs that contain
the entire application, with dependencies. Then, i can set up a local
apt repository, and use apt-get to install my application wherever it's
needed. My servers all grab their security and code updates from my
central apt server. trying to fit CPAN into the mix would get messy :).
-It fits with the debian way of doing things. almost everything in
my production environments are installed via a .deb. this allows me to
check what i have installed just by using dpkg, and what versions of
each. I try to keep with the OneTrueDebianWay(tm) whenever possible.
this allows me to use things like cruft(8) to see any cruft on the
system. i find this helps when investigating a possible security breach,
or simply making sure the users are not doing anthing 'bad'. Although
telling cruft not to look at my perl libs is trivial, I prefer it my
may. Simpler.
>
> On my development machine, I use Woody because I want a stable
> platform. I add specific backports where necessary, and I use CPAN for
> all my Perl modules and do not have a problem. I'd love to see a
> Debian apt-get that used CPAN instead.
Is that not what dh-make-perl is? a way to use debians package
management with CPAN. With a local apt repository, this is exactly what
you have!
>
> On a production machine, I can see an argument for only using deb
> packages from stable, for robustness and security. But in that case,
> making your own debs from CPAN downloads is just as dangerous.
But what about packages that are not in debian.. you have no choice but
to use dh-make-perl or a CPAN install. i prefer dh-make-perl, but that
is just preference.
>
> For development, why complicate things with yet another package
> manager when Perl already has a brilliant one.
For production, why complicate things with yet another package manager
when Debian already has a brilliant one? :).
I find wrestling with only one package manager (and, in my environments,
the OneTruePackageManager) a lot easier. upgrades are a lot easier as
well. I agree that for development, if one finds CPAN less complicated,
there is no problem. I personally find that using dpkg is the better
way. Having every file installed on my system in a central database
keeps me feeling safe and secure with the knowlege that i understand my
system.
Perhaps it's simply that i know and use dpkg for all my projects,
whereas i've always had trouble with CPAN (the module, not the
repository), and i don't quite understand all of it.
Happy Hacking,
drewc
>
> Cheers, Dave
>
>
_______________________________________________
maypole mailing list
maypole at lists.netthink.co.uk
http://lists.netthink.co.uk/listinfo/maypole
This archive was generated by hypermail 2.1.3 : Thu Feb 24 2005 - 22:25:56 GMT