perl module packages: why do they exist?
>About two months ago, I upgraded a CPAN bundle on a production server.
>Two interesting things happened:
>(1) perl itself got upgraded, and
>(2) wais got upgraded.
Huh??? Perl itself? I don't think this is possible.
>Also, there are CPAN modules whose installation has a step which says
>something to the effect of "you must read the README". The DBD stuff
>that Tim Bunce wrote comes to mind. We can do a lot better.
>Essentially, if you use CPAN, you're always working with UNSTABLE.
Well, of course, I've maintained perl manually on 2 production servers for more than 2 years now, and have never had a problem. I just wait until s/w is a couple of weeks old before upgrading them.
I can see your point and I can see the reason for having official packages and blessed versions of perl modules and all that. I guess it's kinda a moot issue since if I feel like it I can always maintain my modules outside of pacakage control, say, using CPAN.
One thing is gonna burn me is if a package wants, say, perl lwp installed, and I did it in /usr/local/lib/perl/site_perl (i.e., w/ CPAN), the package won't know about that and I'd have to force it to install. Don't know if there's any solution to that.
> I am planning on creating a make-ppkg package that shall
> create perl packages just like make-kpkg creates kernel-image
> packages, but I'm still recovering from a disk crash, and I have
> other commitments at the moment
Seems to me it'd be better to mess with MakeMaker so you could make debian packages right outta the module w/o additional help. Should be doable.
BTW, is anyone working on any Debian-specific Perl modules?
.....A. P. Harris...apharris@onShore.com...<URL:http://www.onShore.com/>
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to email@example.com .