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...
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
