Messed up Perl

[Michael_google gmail_Gersten]

>>> How is having a *_select problem going to be easier for people than using the full path to the >binary they want or having the user modify their $PATH to do what they want?
>>
>> Because the select is done by macports when installed; the user just
>> runs the program, and now gets the macports version.
>
> What you're not understanding is that the situation you are describing is the minority situation. Your proposal is to change things to make it work the way you want at the expense of everyone who wants it to work the other way.
>
> From experience for the project, many more people are confused by the way you describe than are confused by the way it is now.
>
> If you have an idea that doesn't involve inconveniencing the people who like the 'it just works' nature of the current solution, then I for one would be excited.

There are, fundamentally, three types of programs.
1. Programs that I want installed from Macports, where I want the
macports to override the system.
2. Programs that some other program wanted installed, where that
program explicitly calls the new one; I don't want the system program
overridden by default. If I want it overridden, I'll explicitly
request installing that program.
3. Programs that came with the system.

In general, if I have something working, then I have something
working. You seem to be saying that you want the authority to change
something/anything in my environment that I did not ask, want, or know
would be changed.

What I am saying is: Class 2 (programs installed by something as a
dependency) should not override the system by default. If I say "port
echo requested", and it doesn't show up, give me the system version.

What you are saying seems to be: "We did this before, before we had a
way to track what was requested. We get very few complaints, so most
people must prefer this way".

So first, am I understanding you correctly? That few complaints are
received, and the assumption is that few complaints means "Preferred",
rather than "acceptable"?

If not, then let me turn this around: Is there a reasonable way to let
program X installed dependency Y, and yet still let me use system
version of Y?

Python is complex enough that there is an explicit select package for
it. Apparently the same is true for gcc (based on what I've seen come
across the list; I haven't installed a new gcc from macports). Now it
seems that Perl is a "known complex and every packaging system has to
deal with this", which gets right back to needing a select thingie for
it.

> If you have an idea that doesn't involve inconveniencing the people who like the 'it just works' nature of the current solution, then I for one would be excited.

Plain and simple: Want to use macports Y by default when it's
currently just a dependency? "sudo macport setrequested Y". Because
now you are requesting it.

Let all the complexities of package_select be handled for the normal,
default case by macports.

Install a new python? Fine, python_select it by default.
Install a new perl? Fine, perl_select it by default.
Install a new svn? Fine, svn_select it by default.

Install wonder_utility that wants perl-oddball-special_hooks? Don't
change the default perl.

-- 
Political and economic blog of a strict constitutionalist
http://StrictConstitution.BlogSpot.com