[You ([EMAIL PROTECTED])] >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. [Manoj said] > 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. [EMAIL PROTECTED]<URL:http://www.onShore.com/> -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
