Re: Perl 5.004, perl modules, and binary compatibility
-----BEGIN PGP SIGNED MESSAGE-----
Scott Ellis, in an immanent manifestation of deity, wrote:
>As the official version of perl 5.004 is finally out (I must admit I
>haven't installed the debian package yet, but I run webservers with lots
>of perl CGI and can't afford to break them), I have a few questions,
>comments, and thoughts.
Admittedly, I only have perl 5.004 on my two development machines. I
can't afford to install 5.004 on my production machines since they still
run majordomo 1.94.1 which has a bug that's tickled by 5.004.
>1. In building my own perl kit for other machines I maintain, I noticed
>the option to maintain binary module compatibility with 5.003 at the
>expense of a poluted namespace. I assume this option was chosen for the
>debian package.
Definitely. I'm not interested in getting lynched right now...
>2. I also assume that perl being compiled for glibc is going to end up
>being a flag day for all the binary compiled perl modules. May I suggest
>that that would be the ideal time to compile perl with a clean namespace.
>Perhaps upload such a version of perl into experimental to allow the perl
Actually, since debian packages that provide modules go into versioned
namespace, it's not as bad as that. Choosing then to go to a cleaner
namespace sounds like a fine idea. BTW, perl will become perl5 and
provide perl if no one objects too strongly. Brian White should like
this since he asked for it a while back. The upgrade to libc6 for perl
can't happen until there is a libgdbm compatible with it though since I
refuse to break everyone's dbm interfaces. I'll also be able to release
a libperl.so package with a cleaner namespace then.
>3. I also think that any package that provides a perl module should be
>labled as such in its package name. Package names like www-search and
>alias hardly suggest that this is a perl module I'd like to install.
>CGI-modules is hardly better.
I don't think so. This might be a good place for the bundling concept
someone proposed a while back for dselect. The namespace is limited and
shouldn't be cluttered with stuff that's easily readable in the
description. This would be similar to calling tix, tcltk-tix. I'd have
no idea other than reading the description that it's for tcl/tk...
>4. I am also concerned about the ease of upgrading the bundled modules,
>especially CGI.pm and the other CGI:: modules. While I realize they are
>included in the upstream perl kit, the CGI modules especially are likely
>to be upgraded at a far greater rate than perl is. Does perl look at the
>site-perl directory before looking in its normal librarys?
Yes, I expect that CGI and friends will be replaced at a quicker rate.
I'll put Replaces: cgi-modules and Provides: cgi-modules in the perl
package and cgi-modules can put Provides: perl in it's package.
No, Perl doesn't search the site_perl directories first. You can find
this out by type perl -V. This is so that multiple versions can be
installed. (Important for when I start releasing the experimental
packages.) This won't be a problem if cgi-modules is released as a
package since it will simply overwrite the files. CGI.pm is now set up
so that when you do a make install it will put it in the proper place so
that the newest version will be run...
Darren
- --
<torin@daft.com> <http://www.daft.com/~torin> <torin@debian.org> <torin@io.com>
Darren Stalder/2608 Second Ave, @282/Seattle, WA 98121-1212/USA/+1-800-921-4996
@ Do you have your clothes on? I probably don't. Take yours off. Feel better. @
@ Sysadmin, webweaver, postmaster for hire. C/Perl/CGI programmer and tutor. @
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBM4H5Do4wrq++1Ls5AQEbiwQAitdXJ4tTELTDeqDcSDe+raYLMDrkjl0U
VADXU1TDTHKpumAG95BoVoJh+ufwnYf104XLTjgmn/0Gykom4XLPAtDovIishZ9n
wj8NeihTaFS/rSgl6lVOjiDUjkjNWpzxMWm7m64Jk86OYtJHM91DGuye/2PM8GLh
U0xshS3Jb3o=
=YEPC
-----END PGP SIGNATURE-----
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: