Understanding what I am calling the mess that is perl modules

[Ryan Schmidt]

On Jan 21, 2009, at 02:35, Scott Haneda wrote:

> I need Tie::RDBM
> If someone can tell me anything wrong I am doing, or better ways, I  
> would be able to provide more ports back to MacPorts.
>
> `port search p5-tie`
> 4 results, none of which appear to be what I want.
>
> What are the possibilities Tie::RDBM is contained within one of the  
> 4 results macports found?  The answer to that should be 0.  If it  
> is not, I am searching wrong and would like to know how to  
> correctly search.  If I am searching correctly, there needs to be a  
> standard way to resolve this where the contents of a module are put  
> into the port file so it can be searched and found.
>
> I have a feeling the answer is not 0.  That being the case, I would  
> like to suggest no port be approved until this qualification for  
> search is met.  ports may have 5000+ port files, but with this  
> issue solved, it could appear to have many many more.

I'm not sure this issue is limited to Perl modules. What if a user  
knows that they want the program "mogrify", but they do not know what  
software package provides it? "port search mogrify" does not tell  
you. You have to already know that it's provided by ImageMagick.  
MacPorts at this time seems to assume that the user either already  
knows what software package they want to install, or that they can  
find it using keywords from the description.

It might be nice to let the user search by what files are in the  
port. "port contents" tells you what's in a port, but only if it's  
already installed, which isn't very helpful if you're trying to  
figure out which port to install. Problem is the list of files in a  
port is not known to MacPorts until the port is installed. This could  
be more easily done if we had binary packages, but that is a long way  
off. There are also the occasional ports that install different files  
on different systems; one would have to take care that all possible  
files are included in the search.


> I am trying to add in Tie::RDBM and find this page:
> http://search.cpan.org/~lds/Tie-DBI-1.02/lib/Tie/RDBM.pm
>
> Version 0.70, so I would make my port file with a name of:
> p5-Tie-RDBM 0.70
> Which is going to translate to downloading a file of:
> Tie-RDBM-0.70.tar.gz
>
> I am betting dollars to donuts that will fail.  On the cpan page I  
> see they want me to download Tie-DBI-1.02.tar.gz.
>
> And there, I am lost, the version is way off, the name is off,  
> there is no way MacPorts is going to figure this out.

So the MacPorts port should probably be for the entire Tie::DBI 1.02  
package, not just for its Tie::RDBM subpackage. You can ask the author 
(s) of Tie::DBI why they have combined several perl modules into one  
package, but presumably it's because they all work together and  
require one another.


> I actually do not even understand why a port has to be made for  
> anything in CPAN.  I am sure the publish a list of all their  
> modules, how come that list can not just exist in MacPorts, and we  
> can simply issue something like `sudo port install cpan- 
> foo::bar::baz and have MacPorts do the rest.
>
> For items that would not build right away, or if someone wants  
> something tried, true, and tested, there could be a full port file.


I don't recall anyone having discussed such an idea before, so that's  
probably one reason why it hasn't been done. We could have that  
discussion now.

One problem with this approach is that of the version number.  
MacPorts ports are always of a particular version -- one which has  
been tested by its maintainer, or at least, by someone. When a new  
version is released, someone tests it and updates the port. The new  
version may have new bugs the committer didn't see, the new version  
may not even compile for everyone, but at least it was tested in some  
way, presumably on a Mac, by somebody. If you just make MacPorts a  
conduit to CPAN, there would be no testing of those modules by a  
MacPorts user at all.

Consider also how MacPorts works: there is a directory of portfiles,  
and a portindex file that lists them all. "port install" consults the  
index to know if the port exists. "port outdated" consults the index  
to know if your ports are outdated. If there are no portfiles for  
CPAN modules, how would they appear in the index? If they're not in  
the index, how would "port outdated" work? Would we have a separate  
index for CPAN modules?

I'm sure there are several more issues to consider; those are just  
off the top of my head. And of course again they're not limited to  
Perl modules from CPAN. One could also consider how this could apply  
to PHP modules from PEAR and PECL, Ruby gems, Octave packages, etc.