Re: Module::Build and the PPM

[hardburn]

Are PPM/RPM repositories likely to happen or be a good idea?

IMHO, the CPAN repository should be as platform-agnostic as possible. Of course, things in the Win32:: namespace will rarely, if ever, be useful outside Windows. Even so, things on CPAN need to install the same way on a broad range of platforms.

There is an argument that fledgling package systems could make use of the CPAN mirrors instead of going to the trouble of setting up its own mirror system. For those people, I suggest looking at an article I wrote for the Linux Journal a while back on Using Debian Apt-get over Freenet. It makes use of Freenet's FProxy (a gateway that lets you use Freenet over HTTP) to allow any package management system that can support HTTP to use Freenet. The article is specific to Debian, but the approach could probably be generalized to almost any package manager with HTTP support.

(Note that I've stepped away from the Freenet project, so things might have changed since I wrote the article. However, I imagine FProxy is still there and the basic approach will still work.)

[eserte]

It's a common misconception that CPAN is a perl module repository. CPAN is really an everything-about-perl repository. There are some views to this repository and the most popular is the modules view (through CPAN.pm or http://search.cpan.org), but there is also a script directory (http://www.cpan.org/scripts/) and people put perl source and binary distributions or even perl-related emacs lisp files to CPAN.

It's OK for me if people want to put PPMs in their CPAN directory. What looks wrong with the Module-Build generated PPMs is the naming scheme. It should really be module-version-architecture-ppm.tgz or similar. Here are some naming examples of already existing PPMs:

ClearCase-Attache-0.01-PPM.zip
Allegro-0.02_0-ppm-MSWin32-x86-multi-thread-5.6.tar.gz.01-PPM.zip
ppm/Winamp-Control.tar.gz

[hardburn]

If there was a seperate area of CPAN set aside for PPMs, I wouldn't have a problem with it. However, everything that is in the modules section should not be a platform-specific package format. Opening up another section (or sub-section) for special package formats is a possibility.

Essentially, I belive anything in the modules section should have the expectation that it can be downloaded and installed via either CPAN.pm or CPANPLUS.pm. There are a few modules which have a complex installation process which are just too much for an auto-install to handle. Such modules shouls explicitly note this fact in the main POD and README. You can still have CPAN as an everything-about-perl repository, it just shouldn't be in the modules section.

[doom]

eserte:

... or even perl-related emacs lisp files to CPAN ...

Can you tell me where those are? I'd like to see an example of the right way to do it.

[doom]

Okay, so following up the hint that people have been putting emacs lisp on cpan, I went looking for some to see how it's being done (I know cperl-mode.el used to be up there, but it hasn't been for awhile, perhaps because it's becoming part of Gnu emacs).

Anyway, I find that by searching cpan for "emacs" and looking very closely through *all* of the results I turned up some emacs lisp packages I didn't know about:

• pod-mode-0.2
• sepia-0.55

I'm glad to see the "sepia" project (an effort to add features to emacs to compete with the graphical IDEs), but I'm a little disappointed to see that no one seems to have a good way to install elisp and info files using the traditional Makefile.PL. ExtUtils::MakeMaker doesn't seem to have provisions for looking for a good "site-lisp" to install some elisp... the INSTALL directions for sepia just say "put the elisp files somewhere Emacs will find them".

(You see, GNU emacs has no package manager of it's own... I was looking for away to (ab)use CPAN as a substitute.)

[randys]

The only "perl-related emacs list files" I know of is cperl-mode by Ilya in his directory which is my favorite authoring environement.

Randy.