p5 modules, get me started on one

[Ryan Schmidt]

On Jan 21, 2009, at 05:00, Scott Haneda wrote:

>>> List it in the port description?  Will that get searched?  How do  
>>> I even
>>> get a list of what is in these packages from the CPAN site?
>>
>> In the long_description is what I was pondering; if you're running  
>> MacPorts
>> 1.7 'port search' will look in (among other field)  
>> long_description by
>> default, with trunk you'd need to add the --long_description flag  
>> to search
>> it.  Anything more specific to perl modules would mean changing  
>> base and of
>> course deciding first how that would work, etc...

Sigh, "port search" had just been changed in 1.7.0 to include the  
long description. And now we've removed it already? Why?


> Seems an ok way to deal with it, not ideal to me though.  I am not  
> sure if this problem is just perl module related, or is more  
> generic.  If it would be appropriate, the idea of adding a new  
> variable to port files may be a fair idea.
>
> file_contains or whatever is appropriate, which could then be  
> searched on by default.  It seems very common that this comes up.

Please no new variable. It uglies up the port. When reading the  
portfile, I want to be able to concentrate on reading the portfile,  
not wading through a list of files I don't care about. The ncursesw  
portfile is currently 38 lines long but it installs 3311 files; I  
don't want the portfile to grow 3311 lines longer.

Not to mention the nightmare of ensuring that the list is always up  
to date with the port. If I update a port to a new version, I'm not  
going to remember to run some process to get a list of files and copy  
it into the port, in case it has changed since the last version.

Plus, as I mentioned before, the problem that ports can install  
different files depending on the version of Mac OS X or the processor  
architecture or variants or other factors.

Back in the very early days of this project, there *was* a variable  
in the port where the files had to be listed. That was before I was  
with the project. But it looks like some ports used the "contents"  
keyword inside the portfile, and others put it in a separate  
"contents" file which was then include into the portfile. If a  
variant added files, then that variant had to update the contents  
keyword. I believe the reason for this variable was so that port knew  
what files belonged to the port, so that ports could be cleanly  
uninstalled. This was before there was a destroot; now that there is  
a destroot, MacPorts can automatically determine what files are part  
of the port. See for example this revision where the "contents"  
mechanism was removed from the apache port:

http://trac.macports.org/changeset/1772/trunk/dports/www/apache


>> Also, knowing that Net::SMTP is with the base perl5.8 port is  
>> something I
>> just knew because it's part of the perl libnet stuff which was  
>> integrated
>> into perl core some time ago.

[snip]

> The question of "How does a new user know that Net::SMTP is part of  
> the base?" is a problem.

A MacPorts *user* does not need to know that; they just need to know  
what port they ultimately want to install, and install it.

A MacPorts *maintainer* (of perl modules) does perhaps need to know  
that. But I think it's a matter of knowing your corner of the world.  
If you're interested in writing perl modules, you need to know a few  
things about perl, like that it includes a small number of modules;  
once you know that, you can use "port contents perl5.8" to see what  
modules are included.


> Also, is it still true than CPAN can get clobbered by Apple  
> Updates?  This is one of the best selling points of MacPorts.

I suppose that's possible. If you use CPAN with Apple's perl, then  
the modules would go into Apple-owned directories, with which Apple  
is free to do whatever they want when you run Apple updates.

If you use CPAN with MacPorts perl, presumably the modules would go  
in MacPorts-owned directories, so Apple updates wouldn't clobber  
them; on the other hand, MacPorts ports may conflict with manually- 
installed CPAN modules.


> Rarely is it easy :)  Curious, without going into a lot of detail,  
> how does the hugely raves about apt-get and equivalent get past all  
> this?

I don't know what other package managers do. You could ask on their  
mailing lists...