From: Andrew F. <an...@bl...> - 2004-05-20 11:27:07
|
On 2004-05-20, Thomas Leonard <ta...@ec...> wrote: > On Thu, May 20, 2004 at 08:47:18AM -0000, Andrew Flegg wrote: >> >> I've been thinking about the fact that relocatable AppDirs and shared >> libraries packaged as AppDirs are fairly irreconcilable, without hacks >> such as "findrox.py" etc. > > You need some code to put up a dialog box if the library isn't installed, > check the version, etc. It's hardly a 'hack'. No, indeed - a poor choice of words. Of course, something like "findrox.py" is needed, however the hardcoding of paths (even LIBDIRPATH) is. >> the fact that apps are increasingly dependent on finding ROX-*Lib in one >> of several predefined locations. > > One of which is at rox.sourceforge.net. Unless you want to let users > redefine the layout of the Internet itself, that shouldn't be a problem. Is ZeroInstall a requirement for ROX, though? (Yes, it's great, but ZeroInstall actually ends up reneguing on several of the key features of AppDirs (including the user being able to put them where they like, self-compiling on different platforms[1] etc.) > ("predefined locations" is "locations in LIBDIRPATH", of course, so > GoboLinux is free to put it whereever it likes) (Disclaimer: don't like GoboLinux, as again the locations are fixed for /everything/. Yes, some locations need to be fixed for an OS to work, but one of the *really* good things about AppDirs, IMHO, are the relocatablity). However, who sets LIBDIRPATH if shared libraries can be anywhere on the system? Admittedly, one of my concerns was that Rox OS, with its totally non-standard filesystem, wouldn't be able to run current AppDirs, but that's alleviated if LIBDIRPATH is set. >> There's also the issue of if things like terminal emulators are packaged >> as AppDirs, which do you call? How do you know what an AppDir provides? > > What if terminal emulators *aren't* packaged as appdirs? Then which do you > call? But I'm imaginging a future here where any program which requires support files (eg. not things like sed etc.) are packaged as an AppDir so they can be relocated and self-compiled. > (answer: use the configured one, or a default if none is configured) Any thoughts on how this configuration could work? Debian uses its /etc/alternatives, but `update-alternatives' isn't very user friendly IME. [note which AppDirs have been seen] > > ...thus reintroducing the original security problems. If the user didn't > *run* the application, you can't trust it. Just looking at it isn't > enough. Hmm, true. Perhaps some form of lowest common denominator security model, though (which already exists in ROX in terms of recognising things as AppDirs): if the AppDir containing the shared lib is owned by the current user, or some set of trusted users (eg. root) then it's safe to run. For non ZeroInstall users, being able to just download ROX-*Lib and some dependent application, unpack them to some temporary directory and have the app work without having to fiddle with LIBDIRPATH or putting the lib AppDir in some "magic" directory, is a big plus point (IMHO). > I don't really see the problem here. If the user does nothing, a correct > version of ROX-Lib is fetched from rox.sourceforge.net. If the user wishes > to run a different copy (eg, they have modified ROX-Lib) then they either > set some environment variables to point to their copy, or use 0divert to > redirect all access to ROX-Lib to their modified version. Perhaps. But again this comes back to a Zero Install almost being an unstated requirement, which'd be fine - if actually stated ;-) However, that then leads me on to the various things in Zero Install which should be looked at: o [1] compiling different platforms - if I've ZeroInstalled a ROX AppDir which compiles on Solaris, AIX, Linux/x86 etc. but I can only compile it on Linux/x86, what does a user of ZeroInstall do on the non-Linux/x86 OS (even if ZeroInstall never makes it to Solaris, there's still Linux/PPC, Linux/ARM etc.)? Do they have to copy it out to writable storage to compile it? (I don't know, don't have any non-Linux/x86 systems to test on) o The original concern I had with proxies turns out to be valid in my usage pattern: proxy needed at work, proxy not needed at home. I solve this for ROX and my desktop as a whole with a script in my .xsession which checks an interface's IP for being in the work range or not, and happily exports http_proxy. However, /etc/init.d/0install is started at boot, and so'll act on the settings of /etc/wgetrc. My user ID, obviously, can't edit that when I log in. I suppose the sensible thing would be to modify /etc/init.d/0install to either a) allow calling of an external script to set http_proxy etc., or b) allow some form of intelligence some other way as to whether or not a proxy needs to be used by wget. Cheers, Andrew PS. Sorry, this post is probably long and rambly. Shouldn't have resumed it after a gap for an hour long meeting! ;-) -- Andrew Flegg -- mailto:an...@bl... | http://www.bleb.org/ |