#Zend studio 12.0.1 update#
If users update it system wide, they can break OS assumptions. It's complicated because if it's available users to use, they'll use it, and when the OS wants to update or change it in some way it can break user assumptions. The problem of the OS shipping a component for it's own needs that gets used by others is a decades old problem at this point.
Possibly because some are used by the OS to actually do things for the OS (not sure if Apple finally got rid most those dependencies or not). > Also, why is Python a developer tool, but Perl isn't? Or ZSH, for that matter? Does the distinction actually make any sense? Both make the other used of those locations more complicated to reason about. At the same time, it's user installed, so /usr/local seems valid. OS provided packages go into /usr, stuff a user manually compiles and installs goes into /usr/local, but where does a third party package manager put stuff? It's not OS provided, but it is packages and maintained, so /usr seems valid. is different and has/had other constrains and reasons behind usage). For a long time there's generally been three categories of software to track (OS provided, third party managed, manually compiled/installed), and two different locations to put them (/usr, /usr/local. There's long been problems with this on UNIX systems. Because none of this is confusing at all. And a binary exists at that path either way, it's just a stub by default. Note how despite not coming with the OS, `python3` is still placed in the Apple-only `/usr/bin/` directory.
0 kommentar(er)
