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