On Apr 15, 2009, at 04:35, C. Florian Ebeling wrote:
On Wed, Apr 15, 2009 at 11:19 AM, Ryan Schmidt wrote:
On Apr 15, 2009, at 03:03, C. Florian Ebeling wrote:
A ruby port also consists of only 3 or 4 lines of effective code,
if you
use the ruby.setup call from the ruby group file. What worries me
more is the brittleness when you just can pull away dependencies
using the special package manager, gem in the ruby case.
Yes, it would be good to fix it so that users cannot cause that
problem.
I don't see what the correct behaviour is, when having a port that
wraps
over a gem, for instance. When the gem is loadable as ruby library,
then
it is visible to the gem manager, and can be removed as well. Even if
there was a way to make a gem visible but not manipulatable, that
would
be very strange behaviour from a ruby/gem perspective.
So I suggest not trying to stay in control here, but rather act
like for
other dependencies for which we don't exert control (path, lib).
Or do you have an idea how to really fix this problem?
How does the perl5 portgroup handle it? Is it using CPAN to install
the modules, and can they then be uninstalled or upgraded by the user
by using the cpan command?
For the pecl portgroup I'm working on, which will be based on the
existing php5-* module ports, we do not use the pear command to
install, so the user will hopefully not be able to use pear to
upgrade or uninstall either.
Maybe it is simply a user error to use gem or cpan to manipulate
those packages, and users just need to be educated to use MacPorts
for all software installations.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
