Andrew Barnert: > > What are the actual problems with having a root/wheel > > 755 framework directory instead of root/admin 775? I > > guess it means you can't install modules to > > site-packages out of .pkg files? If it's important, it > > would be nice if it were easier to do properly.
Ronald Oussoren: > root/admin 775 makes it easier to install packages when > you're an admin user, you can do away with the call to > sudo. Yeah, but adding sudo at the command line isn't that big a deal. I was assuming there were more serious problems, like installing from a .pkg file (you can't launch the installer as root nearly as easily as you can sudo python or make). And maybe others that I didn't anticipate. Or maybe not. Also, Apple clearly intends things in /Library to be admin 775, so why violate that unless there's a good reason? If it's not that hard to change make frameworkinstall to do the right thing, why not do it? If it'd be easier to understand a patch rather than an explanation, just let me know. If you understand what I'm getting at and I'm just being stupid (which is quite possible), please tell me what I'm missing. [re: darwinports and frameworkinstall] > > I'm guessing it would help the darwinports and fink > > guys out, too. Last I checked, fink wouldn't build > > Python at all on Intel, and darwinports wouldn't do a > > framework install--but even on PPC, they both ended up > > with a root/wheel 755 framework directory. > > I don't use fink, and use darwinports only for unix-y tools, > IMHO neither should have to use framework installs :-) OK, my writing was a bit unclear. The "Last I checked" part was a parenthetical aside; the "root/wheel 755" part was the main issue. If the only problems with wheel 755 are with .pkg files (which you're probably not going to use with darwinports or fink) and needing sudo (which doesn't matter, since you always sudo port install), I guess that's no problem. But it would still be fixed automatically if make frameworkinstall were changed. As for the side issue with framework builds: If darwinports is going to include a python2.4 that installs Idle.app, and ports like py-appscript, it needs to either build a framework or find some other way to get a working pythonw. Otherwise you get an Idle that won't run, an appscript that can't be used, etc. You could argue that darwinports shouldn't have these ports at all, I guess. But if they have them, the ports should work. BTW, darwinports is actually pretty useful for Mac-y tools as well as unix-y tools. When I first got my Intel iMac, I was able to install Bwana-Dik, Smultron, CocoaDialog, etc. in a few minutes, even though none of them had an official Intel or universal build. No different from svk, pngcrush, links, and other unix-y ports. [re: tests] > According to buildbot > (www.python.org/dev/buildbot/trunk) > the trunk shouldn't have any test failures. As I said, none of these failures happened on a linux box, or a PPC Mac, so I assume it's something (or some things) specific to Intel Macs. Since buildbot doesn't have an Intel Mac, I wouldn't expect it to find them. So, should I file bugs? _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
