ruby_select plan, rubygem: dependency operator

[Ryan Schmidt]

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.