From: Tony H. <h...@re...> - 2005-03-22 23:16:24
|
Seeing as I've now got 4 PCs running ROX on Debian I'm thinking it would be easier in the long run to make some Debian packages for the ROX applications I use. The trouble is ROX's appdir concept just doesn't fit in to Unix so there's no place for it in the FHS. It would probably be valid to put it in /opt, but Debian doesn't use /opt, and I don't have a partition for it, so I want to avoid that. I think it might be best to use /usr/share/rox-desktop (and have a rox-desktop pseudo package which pulls in ROX-Filer, ROX-Session etc so that the above directory has a "right" to exist) with an Apps subdirectory. But /usr/share must be architecture-independent so I'd have to move the binaries into /usr/bin or /usr/libexec and modify the AppRun scripts. Does that sound sensible? -- TH * http://www.realh.co.uk |
From: Tristan M. <the...@gm...> - 2005-03-23 01:58:25
|
On Tue, 22 Mar 2005 23:15:51 +0000, Tony Houghton <h...@re...> wrote: > I think it might be best to use /usr/share/rox-desktop (and have a > rox-desktop pseudo package which pulls in ROX-Filer, ROX-Session etc so > that the above directory has a "right" to exist) with an Apps > subdirectory. But /usr/share must be architecture-independent so I'd > have to move the binaries into /usr/bin or /usr/libexec and modify the > AppRun scripts. Does that sound sensible? That sounds complicated! What's wrong with /usr/apps, variations upon which seem to be the norm. -- Tristan |
From: Tony H. <h...@re...> - 2005-03-23 16:13:15
|
In <e57...@ma...>, Tristan McLeay wrote: > On Tue, 22 Mar 2005 23:15:51 +0000, Tony Houghton <h...@re...> wrote: > > > I think it might be best to use /usr/share/rox-desktop (and have a > > rox-desktop pseudo package which pulls in ROX-Filer, ROX-Session etc so > > that the above directory has a "right" to exist) with an Apps > > subdirectory. But /usr/share must be architecture-independent so I'd > > have to move the binaries into /usr/bin or /usr/libexec and modify the > > AppRun scripts. Does that sound sensible? > > That sounds complicated! What's wrong with /usr/apps, variations upon > which seem to be the norm. I don't think you're supposed to go making up directories in the top-level of /usr. I know the old Debian packages did something like that, but I don't think they really should have done. I've noticed there is an up-to-date Debian package of rox-filer after all, and that splits it up into /usr/share etc. I think that's the least of the available evils, because it only makes things complicated for the package maintainer while, if anything, easier for end users. But I'd ultimately like to have packages for rox-session, OroboROX and several useful applications, and make it easy and quick for new users to get a useful Apps folder instead of having to rummage around in an overcrowded /usr/share for ROX apps. So a central location for app dirs, and nothing but app dirs, is still required, preferably within the rules of the FHS without using /opt. -- TH * http://www.realh.co.uk |
From: Thomas L. <ta...@ec...> - 2005-03-23 19:02:17
|
On Wed, Mar 23, 2005 at 04:12:45PM +0000, Tony Houghton wrote: [...] > But I'd ultimately like to have packages for rox-session, OroboROX and > several useful applications, and make it easy and quick for new users to > get a useful Apps folder instead of having to rummage around in an > overcrowded /usr/share for ROX apps. So a central location for app dirs, > and nothing but app dirs, is still required, preferably within the rules > of the FHS without using /opt. How about updating the debs for 0install? Then you can find all your apps in /uri/0install/rox.sourceforge.net/apps ... -- Thomas Leonard http://rox.sourceforge.net tal at ecs.soton.ac.uk tal197 at users.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Arioch <the...@nm...> - 2005-03-29 22:02:13
|
Tony Houghton =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > So a central location for app dirs, =2E..or softlinks to app dirs ? |
From: Tony H. <h...@re...> - 2005-03-29 22:11:51
|
In <d2cj0e$lsc$2...@se...>, Arioch wrote: > Tony Houghton ??????????: > > >So a central location for app dirs, > ...or softlinks to app dirs ? A central location, or its contents, would need to be soft-linked into the user's desktop somehow, but with a package manager like dpkg/apt there does need to be a central location, because they install packages for the whole system, not just for one user. -- TH * http://www.realh.co.uk |
From: Arioch <the...@nm...> - 2005-03-30 09:00:52
|
Tony Houghton =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > A central location, or its contents, would need to be soft-linked into > the user's desktop somehow, but with a package manager like dpkg/apt > there does need to be a central location, because they install packages= > for the whole system, not just for one user. >=20 Sorry, but Rox makes it's own system of deivering software, so why=20 You're are talking of packages installed before Rox, by tools like rpm/ap= t ? Are You meaning that Rox should make itself familiar to those=20 pre-installed applications and somehow include them into it's own /Apps? Then it is to rely in freedesktop.org menu standard IMHO, but that=20 standard provides their own logical separation of application 'by=20 topics, submenus', wich might differ from Rox's one. At least Rox will=20 get the list of apps. |
From: Tony H. <h...@re...> - 2005-03-30 13:47:36
|
In <d2dpmc$i07$1...@se...>, Arioch wrote: > Tony Houghton ??????????: > > >A central location, or its contents, would need to be soft-linked into > >the user's desktop somehow, but with a package manager like dpkg/apt > >there does need to be a central location, because they install packages > >for the whole system, not just for one user. > > > > Sorry, but Rox makes it's own system of deivering software, so why > You're are talking of packages installed before Rox, by tools like rpm/apt ? > Are You meaning that Rox should make itself familiar to those > pre-installed applications and somehow include them into it's own /Apps? > Then it is to rely in freedesktop.org menu standard IMHO, but that > standard provides their own logical separation of application 'by > topics, submenus', wich might differ from Rox's one. At least Rox will > get the list of apps. I just want ROX to be installable with package managers like rpm and apt, and to be able to provide a default desktop for all users of a PC. Many potential ROX users have to learn how to use one of those anyway, so why not take advantage of them to make installing ROX easier? 0install looks really good, but although it has a shared cache, each user still has to set up their own desktop. And AFAICT, each compile their own binary, which is wasteful of time and space. I'm also a bit concerned about how it fetches libraries that appliactions depend on, eg pygtk. Can it detect if a perfectly usable copy has already been installed by a package manager? Downloading an extra version is at best another waste of time and space, and at worst could cause conflicts. -- TH * http://www.realh.co.uk |
From: Matthew W. O'P. <mwe...@gm...> - 2005-03-30 15:23:15
|
On Wed, 30 Mar 2005 14:47:12 +0100, Tony Houghton <h...@re...> wrote: > In <d2dpmc$i07$1...@se...>, Arioch wrote: > > > Tony Houghton ??????????: > > > > >A central location, or its contents, would need to be soft-linked into > > >the user's desktop somehow, but with a package manager like dpkg/apt > > >there does need to be a central location, because they install packages > > >for the whole system, not just for one user. > > > > > > > Sorry, but Rox makes it's own system of deivering software, so why > > You're are talking of packages installed before Rox, by tools like rpm/apt ? > > Are You meaning that Rox should make itself familiar to those > > pre-installed applications and somehow include them into it's own /Apps? > > Then it is to rely in freedesktop.org menu standard IMHO, but that > > standard provides their own logical separation of application 'by > > topics, submenus', wich might differ from Rox's one. At least Rox will > > get the list of apps. > > I just want ROX to be installable with package managers like rpm and > apt, and to be able to provide a default desktop for all users of a PC. > Many potential ROX users have to learn how to use one of those anyway, > so why not take advantage of them to make installing ROX easier? > > 0install looks really good, but although it has a shared cache, each > user still has to set up their own desktop. And AFAICT, each compile > their own binary, which is wasteful of time and space. I'm also a bit > concerned about how it fetches libraries that appliactions depend on, eg > pygtk. Can it detect if a perfectly usable copy has already been > installed by a package manager? Downloading an extra version is at best > another waste of time and space, and at worst could cause conflicts. This has been an issue I've had with 0install, actually. I've installed it on systems that have perfectly usable pygtk installs, and yet I'll get error messages saying pygtk is missing or an improper version. Additionally, I've found that if my machine cannot connect to the 0install server, then I also get errors (though theoretically it should handle such a situation gracefully). I really *want* to like and use 0install, but from a practical perspective, it simply doesn't seem to work for me. -- Matthew Weier O'Phinney mwe...@gm... http://weierophinney.net/matthew/ |
From: Thomas L. <ta...@ec...> - 2005-03-30 16:05:10
|
On Wed, Mar 30, 2005 at 10:22:49AM -0500, Matthew Weier O'Phinney wrote: > On Wed, 30 Mar 2005 14:47:12 +0100, Tony Houghton <h...@re...> wrote: [...] > > I just want ROX to be installable with package managers like rpm and > > apt, and to be able to provide a default desktop for all users of a PC. > > Many potential ROX users have to learn how to use one of those anyway, > > so why not take advantage of them to make installing ROX easier? > > > > 0install looks really good, but although it has a shared cache, each > > user still has to set up their own desktop. And AFAICT, each compile > > their own binary, which is wasteful of time and space. I'm also a bit > > concerned about how it fetches libraries that appliactions depend on, eg > > pygtk. Can it detect if a perfectly usable copy has already been > > installed by a package manager? Theoretically, yes. ROX-Lib will use either a local copy of PyGTK or a zero install one, for example. However, it prefers the Zero Install copy at present (it's easier for testing if we don't have to worry about people's local versions). However, some distros have compiled python in a way that makes it binary incompatible with python modules compiled on other distros, so we try both. > > Downloading an extra version is at best another waste of time and > > space, and at worst could cause conflicts. How can it cause conflicts? It only goes in the cache... > This has been an issue I've had with 0install, actually. I've installed it on > systems that have perfectly usable pygtk installs, and yet I'll get error > messages saying pygtk is missing or an improper version. Odd, since it tries both. You could try using 0divert to stop it using the zero install version at all. > Additionally, I've found that if my machine cannot connect to the > 0install server, then I also get errors (though theoretically it > should handle such a situation gracefully). That can happen if you refresh and then go off-line. It knows that its cached copy is out-of-date, but it can't get the new version. The injector solves that, though, since you can just set the network policy to 'Off-line' and it will fall back to the cached version. Are you able to run Edit using it? Try: $ 0alias rox-edit http://rox.sourceforge.net/2005/interfaces/Edit $ rox-edit (the latest version is at http://0install.net/injector.html) Let me know if you get errors... -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Guido S. <__g...@we...> - 2005-03-23 12:30:19
|
On Tue, 22 Mar 2005 23:15:51 +0000 Tony Houghton <h...@re...> wrote: > The trouble is ROX's appdir concept just doesn't fit in to Unix so > there's no place for it in the FHS. It would probably be valid to put it > in /opt, but Debian doesn't use /opt, and I don't have a partition for > it, so I want to avoid that. ROX fits perfectly into Unix. /opt/vendor/app has been a official UNIX standard since 1988. What you mean is, it doesn't fit into Debian packaging policy or most other idiosyncratric Linux distro policies. Debian doesn't follow any FHS standard other than its own. > I think it might be best to use /usr/share/rox-desktop (and have a > rox-desktop pseudo package which pulls in ROX-Filer, ROX-Session etc so > that the above directory has a "right" to exist) with an Apps > subdirectory. But /usr/share must be architecture-independent so I'd > have to move the binaries into /usr/bin or /usr/libexec and modify the > AppRun scripts. Does that sound sensible? I'm sorry, from where I stand, this sounds pretty sick. I'm not a Debian user, so I'll stop here. I don't like how I'm starting to sound like a troll. |
From: Tony H. <h...@re...> - 2005-03-23 15:32:40
|
In <200...@we...>, Guido Schimmels wrote: > On Tue, 22 Mar 2005 23:15:51 +0000 > Tony Houghton <h...@re...> wrote: > > > The trouble is ROX's appdir concept just doesn't fit in to Unix so > > there's no place for it in the FHS. It would probably be valid to put it > > in /opt, but Debian doesn't use /opt, and I don't have a partition for > > it, so I want to avoid that. > > ROX fits perfectly into Unix. > /opt/vendor/app > has been a official UNIX standard since 1988. > What you mean is, it doesn't fit into Debian packaging policy or most other idiosyncratric Linux distro policies. > Debian doesn't follow any FHS standard other than its own. It looks like I might have to use /opt then. I was against it on practicality grounds rather than ideology though. Debian doesn't use /opt for anything else, so it effectively isn't supported (AFAICR lack of /opt/bin in PATH etc, no suggestion that an /opt partition should be created at installation). Whether Debian are right or wrong not to use /opt, the fact is it would be easier for end-users if I also didn't use it. And we'd need to register with LANANA; is that straightforward or unbearably bureaucratic? > > I think it might be best to use /usr/share/rox-desktop (and have a > > rox-desktop pseudo package which pulls in ROX-Filer, ROX-Session etc so > > that the above directory has a "right" to exist) with an Apps > > subdirectory. But /usr/share must be architecture-independent so I'd > > have to move the binaries into /usr/bin or /usr/libexec and modify the > > AppRun scripts. Does that sound sensible? > > I'm sorry, from where I stand, this sounds pretty sick. > I'm not a Debian user, so I'll stop here. > I don't like how I'm starting to sound like a troll. What's sick about it, do you mean splitting up the contents of app dirs? Package managers (and stow) address the disadvantages of doing that. And there are still some disadvantages of app dirs as shown by the kludge of ROX-Filer having to install an extra rox script in PATH. OroboROX would need a similar kludge to make it easier to use as a wm in other environments. And that kludge would ironically make things much easier for new ROX users too, because without it, it's just about the only wm ROX-Session can't offer as an option at installation because it doesn't know where to find it. Although that could be alleviated by ROX having its own path to search for runnable app dirs. I tend to agree that app dirs are a better concept for GUI environments than following Unix FS layout concepts, but saying that Debian is wrong doesn't get ROX into Debian, especially when ROX doesn't actually make a very strong case for app dirs, as I've outlined in the above paragraph. -- TH * http://www.realh.co.uk |
From: Guido S. <__g...@we...> - 2005-03-23 18:17:27
|
On Wed, 23 Mar 2005 14:10:25 +0000 Tony Houghton <h...@re...> wrote: > In <200...@we...>, Guido Schimmels wrote: > > > On Tue, 22 Mar 2005 23:15:51 +0000 > > Tony Houghton <h...@re...> wrote: > > > > > The trouble is ROX's appdir concept just doesn't fit in to Unix so > > > there's no place for it in the FHS. It would probably be valid to put it > > > in /opt, but Debian doesn't use /opt, and I don't have a partition for > > > it, so I want to avoid that. > > > > ROX fits perfectly into Unix. > > /opt/vendor/app > > has been a official UNIX standard since 1988. > > What you mean is, it doesn't fit into Debian packaging policy or most other idiosyncratric Linux distro policies. > > Debian doesn't follow any FHS standard other than its own. > > It looks like I might have to use /opt then. I was against it on > practicality grounds rather than ideology though. Debian doesn't use > /opt for anything else, so it effectively isn't supported (AFAICR lack > of /opt/bin in PATH etc, no suggestion that an /opt partition should be > created at installation). Whether Debian are right or wrong not to use > /opt, the fact is it would be easier for end-users if I also didn't use > it. And we'd need to register with LANANA; is that straightforward or > unbearably bureaucratic? I can't give you advice in dealing with Debian. The absence of /opt in Debian is of course ideological. /opt is meant for 3rd parties, and the concept of 3rd-party doesn't exist in Debian AFAIK. But if Debian policy doesn't allow for /usr/apps, /opt is the logical next choice. > > > I think it might be best to use /usr/share/rox-desktop (and have a > > > rox-desktop pseudo package which pulls in ROX-Filer, ROX-Session etc so > > > that the above directory has a "right" to exist) with an Apps > > > subdirectory. But /usr/share must be architecture-independent so I'd > > > have to move the binaries into /usr/bin or /usr/libexec and modify the > > > AppRun scripts. Does that sound sensible? > > > > I'm sorry, from where I stand, this sounds pretty sick. > > I'm not a Debian user, so I'll stop here. > > I don't like how I'm starting to sound like a troll. > > What's sick about it, do you mean splitting up the contents of app dirs? > Package managers (and stow) address the disadvantages of doing that. And > there are still some disadvantages of app dirs as shown by the kludge of > ROX-Filer having to install an extra rox script in PATH. OroboROX would > need a similar kludge to make it easier to use as a wm in other > environments. And that kludge would ironically make things much easier > for new ROX users too, because without it, it's just about the only wm > ROX-Session can't offer as an option at installation because it doesn't > know where to find it. Although that could be alleviated by ROX having > its own path to search for runnable app dirs. Such exists: APPDIRPATH, LIBDIRPATH. Yes, that's a flaw in ROX-Session. You really need only one such script in PATH. Under NeXTstep/GNUstep/MacOS X it's called "openapp", the closest we have on ROX is rox_run provided with ROX-Clib. > I tend to agree that app dirs are a better concept for GUI environments > than following Unix FS layout concepts, but saying that Debian is wrong > doesn't get ROX into Debian, especially when ROX doesn't actually make a > very strong case for app dirs, as I've outlined in the above paragraph. ROX has no chance in converting the world of Linux to the appdir paradigm, so we must provide it as subsystem somewhat seperate from the remaining distro. Btw. GNUstep normally lives under /usr/GNUstep. Debian changes this to /usr/lib/GNUstep. So that's what you could do for ROX. So we would get: /usr/lib/ROX/apps. On MacOS X the equivalent is: /Applications which further highlights that ROX needs its own distribution to live up to its full potential. If I wasn't on dial-up still, that might have come into existance a year ago already :( |
From: Tony H. <h...@re...> - 2005-03-23 18:39:25
|
In <200...@we...>, Guido Schimmels wrote: > Btw. GNUstep normally lives under /usr/GNUstep. Debian changes this to > /usr/lib/GNUstep. So that's what you could do for ROX. So we would > get: > > /usr/lib/ROX/apps. Yes, I suppose there is the option of the /usr/lib dumping ground. Official Debian people would probably be inclined to reject that on the grounds that /usr/lib shouldn't be a dumping ground, and they only made an exception for GNUstep because it's already well-established. But if Debian doesn't make proper provision for this sort of thing... I think I'll ask for advice on uk.comp.os.linux where there are a lot more Debian users. -- TH * http://www.realh.co.uk |
From: Jonatan L. <th...@ho...> - 2005-03-23 20:40:09
|
On Wed, 23 Mar 2005 19:17:06 +0100 Guido Schimmels <__g...@we...> wrote: > ROX has no chance in converting the world of Linux to the appdir > paradigm, so we must provide it as subsystem somewhat seperate from > the remaining distro. > > Btw. GNUstep normally lives under /usr/GNUstep. Debian changes this > to /usr/lib/GNUstep. So that's what you could do for ROX. So we would > get: > > /usr/lib/ROX/apps. > > On MacOS X the equivalent is: > /Applications I have mine in /ROX-Apps on GoboLinux. (Where all the non-appdir programs lives in /Programs, one for each app). Works great! > which further highlights that ROX needs its own distribution to live > up to its full potential. If I wasn't on dial-up still, that might > have come into existance a year ago already :( How's it going with RoxOS? I think the idea is great, as long as you can keep compatibility for standard linux apps that hasn't been or can't be converted to AppDir. Is the RoxOS webpage up to date? /Jonatan -=( http://kymatica.com )=- |
From: Guido S. <__g...@we...> - 2005-03-23 23:32:42
|
On Wed, 23 Mar 2005 21:44:50 -0300 Jonatan Liljedahl <th...@ho...> wrote: > How's it going with RoxOS? I think the idea is great, as long as you can > keep compatibility for standard linux apps that hasn't been or can't be > converted to AppDir. Is the RoxOS webpage up to date? There is no application which cannot be converted. Only making them relocatable is often quite involved. Unfortunately it's mainly the gnome apps which are the trouble-makers. Others are mostly trivial to fix. KDE apps work out of the box, due to the sane resource finding API. Just add the APP_DIR to KDEDIRS in AppRun and you are done. I've done the work for the most prominent gnome apps though. Except for Evolution, that hackjob is bona fide a nightmare to package. Of course you could always simple install to /usr/local. But then you need a ROX-Wrapper anyway. I have a AppDir template where I just pop in the source and compile, which is no more work. Only relocatability is not automatic. I could use binreloc, but I think I don't like it. It's a hack that shouldn't be needed. The webpage hasn't seen an upgrade in over a year. RoxOS development is happening solely on my box. There isn't terribly much missing except an installer and a decent networking infrastructure. Linux networking is very ingrained in distro-specifics. There is no package you could simply download and install. I tried to use the fedora network scripts, with modest success. I'm having a look at ALT Linux's /etc/net project, which looks clean and portable. But there is no GUI tool which will work with that (they are writing their own based on gtkmm, which is in a very early state). Hardware detection is also not very mature, but that's due to the immature ever moving Linux hotplugging. udev breaks in wonderfull new ways with every release. |
From: Arioch <the...@nm...> - 2005-03-29 21:58:12
|
Guido Schimmels =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > I'm having a look at ALT Linux's /etc/net project, which looks clean an= d portable. But there is no GUI tool which will work with that (they are = writing their own based on gtkmm, which is in a very early state). To be true, there are two projects :-) AltLinux Alterator is to have a proper backend when somewhen 3.0 would=20 be released, as well /etc/net project has it's own GUI attempt. Anyhow, /etc/net is yet very early project, it is changing rather fast,=20 i'm afraid any GUI tool can become a brake now. About compatibility... the thingie for me is ifplugd integration, for=20 example. Seems there is bug-cmpatibility measures in it, and they make=20 troubles for /etc/net. Seems /etc/net must become a force to change=20 other tools, and it will not before those tools would be changed :-( |
From: Michel S. <mic...@gm...> - 2005-03-30 19:53:11
|
On Wed, 23 Mar 2005 14:10:25 +0000, Tony Houghton <h...@re...> wrote: > It looks like I might have to use /opt then. I was against it on > practicality grounds rather than ideology though. Debian doesn't use > /opt for anything else, so it effectively isn't supported (AFAICR lack > of /opt/bin in PATH etc, no suggestion that an /opt partition should be > created at installation). Whether Debian are right or wrong not to use > /opt, the fact is it would be easier for end-users if I also didn't use > it. And we'd need to register with LANANA; is that straightforward or > unbearably bureaucratic? >=20 The app dirs do not have to be in the path anyway, as I see it, since you'll either be executing them from within the ROX Filer? --=20 Michel Salim =AAL=B4=BC=ABi http://salimma.livejournal.com |