On Jan 21, 2009, at 1:40 AM, Bryan Blackburn wrote:
On Tue, Jan 20, 2009 at 05:50:23PM -0800, Scott Haneda said:
On Jan 20, 2009, at 5:01 PM, Bryan Blackburn wrote:
[...]
Some perl modules come packaged in groups like that, which
definitely
can
cause confusion. Maybe the best solution would be to list all
actual
modules installed with the given port? Then it may be easier to
search
for
it.
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...
Nice to know, thanks, I was not aware of --long_description
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.
[...]
The base perl5.8 port should actually have what's in libnet like
Net::SMTP,
so no port should actually be needed for this one.
How would I know that?
port search smtp
All I see is
p5-net-smtp_auth @0.08 (perl)
Perl5 SMTP client with AUTHentication
If that is it, great, but how would I confirm it is in fact the same
thing? All signs point to it being different.
In many cases, a person running 'port install ...' is probably more
interested in some final program and not just perl modules, so
that's where
the dependency management comes into play. This way various port
maintainers only need to determine the which/where question the one
time for
these things and anyone else just lets port take it from there.
Correct, and the more I think about it, the more I may be looking at
this wrong. My end game here is to get ASSP ported. I need 20 or so
perl modules to go with it, but once I get those, and build the
dependency tree in the ASSP port file, no other user will ever care
about the issues I am currently running into.
If you're one of those maintainers, then it definitely helps to know
the
software you're dealing with. In perl's case, what I've done in the
past is
to query search.cpan.org for the specific module, which leads you to
either
a distribution specific to that module or one that includes several
modules.
That is exactly where I have been spending my time as well. To be
honest, I just wish the developer of ASSP had listed the parent perl
module rather then the submodule, it would have made this seem a heck
of a lot easier.
From that you'd just create the port and be done with it.
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.
And that there is the main major problem with this. While not with
Net::SMTP, but other perl modules, this bit me. I need net:foo and
did not find it, so I made a port. I later learned net:foo was
already in net:main so I wasted my time making the port. In this
case, these ports are mostly copy and paste, so not a big deal, but it
could have been a larger waste of time.
This is the main thing I think needs solving, and it sounds like it
can, with better search, a new field in the port file, and or
automatic retrieval of some perl module index file that has some
mappings in it. It may take all those suggestions, I am not sure.
The question of "How does a new user know that Net::SMTP is part of
the base?" is a problem.
Beginning to dislike perl and I have not written more than 100
lines of it
in my life :)
One advantage is the massive amount of modules already written to
reduce the
amount of work you have to do; one disadvantage is all of the
massive amount
of modules one must wade through to determine what you might
actually need.
Of course using CPAN makes that easier but then that installs
outside of
port, which means you can't depend on it for other ports or use
uninstall/activate/deactivate to manage it, etc.
Also, is it still true than CPAN can get clobbered by Apple Updates?
This is one of the best selling points of MacPorts.
I guess what I'm trying to say is, if there's an easy answer, I
haven't
heard it.
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?
--
Scott
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
