This is the mail archive of the
mailing list for the Cygwin project.
Re: libwin32-perl-0.191 (ready for upload and testing)
- From: "Gerrit P. Haase" <gerrit at familiehaase dot de>
- To: "Rafael Kitover" <rkitover at hotmail dot com>
- Cc: "'Nicholas Wourms'" <nwourms at netscape dot net>, cygwin-apps at sources dot redhat dot com
- Date: Wed, 31 Dec 2003 17:08:41 +0100
- Subject: Re: libwin32-perl-0.191 (ready for upload and testing)
- Organization: Esse keine toten Tiere
- References: <Law9-OE27S7D0KJgqUM0001ab0a@hotmail.com>
- Reply-to: "Gerrit P. Haase" <gerrit at familiehaase dot de>
>>Now that it seems we'll be providing perl module packages, I think we
>>should come up with some sort of naming standard for consistency. For
>>example, Red Hat prefixes their perl packages with "perl-" and
>>generally uses the same case as is found on CPAN. So if we were to
>>adopt this route, this package would be perl-libwin32-0.191-1.
> Either that or libFOO-perl, like in Debian:
> http://mirrors.kernel.org/debian/pool/main/libg/ for an example,
> (packages.debian.org is still down.)
I'm also in favour for the Debian way. So you see the modules name in
the first place (libwww, libnet, libwin32, ...).
>>1) Man pages are good, especially since they can be indexed and keyed.
>> Have builders use make manifypods prior to make install.
> Sounds good, also, an issue I brought up earlier is that on NTFS
> filesystems you can't have "::" in file names, so a Perl user accustomed
> to typing "man IO::File" will be surprised to find nothing there.
> Perldoc still works fine of course, but the man page does exist and is
> just called "IO.File".
> So a year ago or so I made a patch for man to translate "::" sequences
> to "." on Win32. Haven't done anything with it yet, not sure how good
> the code is or if it will apply to the latest version of man, but
> attaching it to this message for reference.
This sounds useful, Volker Zell is the man maintainer, ask him about it.
>>2) Try not to clobber the perllocal.pod, but rather come up with a way
>> to update it (perhaps regenerate it from a pool of fragments?).
> Taking a hint from a debian/rules file for a package from Debian, I have
> used "make pure_install" instead of "make install" which does not
> clobber perllocal.pod, but does not add anything to it either.
> Having a script like "update-perllocal" would be nice of course.
I think it is not that important to include these info into
perllocal.pod, just don't touch it?
>>3) Make a vendorinstalldir for Cygwin, to keep our mods separate from
>> user's local mods, but provide a stable api for dependencies like
>> mod-perl or what-not.
> Another thought, on FreeBSD ExtUtils::MakeMaker (or a related module) is
> somehow smart enough to add module installs to the FreeBSD package
> database, and the packages are called "p5-<FOO>-bsdpan" or something of
> that sort.
> Perhapse we should patch MakeMaker to automatically add package
> information for modules users compile from CPAN into a package space
> like CPAN-lib<FOO>-perl or similar. And at least create an
> /etc/setup/foo.lst.gz so that "rebaseall" will work on user-installed
Michael Schwern is the MakeMaker maintainer, I guess he won't object if
you patch MM up.