How image installs work [was Re: The image question]
Daniel J. Luke
dluke at geeklair.net
Sat Mar 10 08:41:52 PST 2007
On Mar 10, 2007, at 11:33 AM, Jordan K. Hubbard wrote:
>>> I'm sure you meant that in jest, but actually, that assertion is
>>> completely correct. In order to install all at the same time, we
>>> require the user to take the hit of figuring out how to invoke
>>> the others.
>> And any other method of choosing between the two will require the
>> user to figure out how to invoke the others as well (it'll just be
>> a different way of choosing).
> I think you missed my point entirely. If the notion of activate/
> deactivate is part of the "usage ethos" that users are already
> comfortable with then they just need to know that things like "gnu
> make" and "bsd make" exist as available packages/options.
If the notion of using bsdmake or gnumake to invoke the appropriate
make is part of the "usage ethos" that users are already comfortable
with, then they just need to know that they both exist.
> Either way, however, it's /usr/bin/make.
That's true, and potentially useful. I'm just not sure it's as
critical a part of usability as you seem to think it is. In either
case, the user still needs to know which packages are available and
manually choose which one they want to use (either by activate/
deactivate or by a unique name).
>>> All casualties of a static namespace.
>> images doesn't make the namespace dynamic, it just standardizes
>> the differentiator into a long/obscure path.
> That is incorrect.
I don't see how, but I'm happy to be corrected (it does cover the
long/obscure path with sym/hard links when you activate a particular
port ... like how gnumake could be installed as both make and gnumake
- and perhaps that is what you're referring to?).
Daniel J. Luke
| *---------------- dluke at geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-users/attachments/20070310/87d12226/PGP.bin
More information about the macports-users