From: MJ R. <ma...@cl...> - 2001-08-23 10:29:58
|
Following are two scripts to build a folder in ROX's Apps directory from the contents of the debian menu system. I'm not sure this is the best way to do it, but they work. I haven't tested this on the latest ROX because the debian packages are incompatible with the released version of debian (potato) and the debianised source does not download from the archive with apt-get source. While it isn't that much effort to do it manually, I don't have much time just now. Are there plans to make the ROX debs compatible with the current release? Here are the scripts. I hope they're useful. -------- 8< -------- /etc/menu-methods/rox -------- 8< -------- #!/usr/sbin/install-menu # -*- mode: shell-script; -*- #I need menu-1.4! # #NOTE: the first line of this script _must_ be # equal to "#!/usr/sbin/install-menu", otherwise update-menus # will feed this script old-compat-mode data. # #More info: /usr/doc/menu/html. # # Copyright 2001 MJ Ray <mj...@to...> # Licensed under the GNU General Public License. # compat="menu-1" !include menu.h compat="menu-2" function ex($com)="makeroxapp '" $section "' '" $com "' '" $package "' '" $icon "'\n"; supported; x11= ex($command); text= ex(term()); endsupported; preoutput="#!/bin/bash\n\n"; treewalk="cm"; genmenu="/buildroxapps"; startmenu=""; endmenu=""; rootprefix="/usr/apps"; userprefix="/src/sapphire/related/MenuDev/menu"; mainmenutitle="DebianMenu"; prerun="rm -r " prefix() "/Debian"; postrun="cd " prefix() " && chmod +x buildroxapps && ./buildroxapps && rm buildroxapps"; -------- 8< -------- -------- 8< -------- -------- 8< -------- -------- 8< -------- /usr/bin/makeroxapp -------- 8< -------- #!/bin/bash # # Copyright 2001 MJ Ray <mj...@to...> # Licensed under the GNU General Public License. # # Params are location/name executable packagename icon # Make the directory mkdir -p "./$1" # Link documentation ln -s "/usr/share/doc/$3" "./$1/Help" # Have a go at symlinking the executable, else use a script if [ -x "$2" ] ; then ln -s "$2" "./$1/AppRun" else echo -e "#!/bin/bash\n# Made by a menu-method\n$2\n" >"./$1/AppRun" chmod +x "./$1/AppRun" fi # Try to find the icon for symlinking if [ -e "$4" ] ; then ln -s "$4" "./$1/AppIcon.xpm" else if [ -n "$4" ] ; then ICON=$(locate "$4" | head -1) if [ -n "$ICON" ] ; then ln -s $ICON "./$1/AppIcon.xpm" fi fi fi -------- 8< -------- -------- 8< -------- -------- 8< -------- |
From: Marcin J. <ma...@am...> - 2002-10-22 15:19:36
|
For those which didn't do "apt-get update" each day I have a news. Yesterday I updated Debian packages for rox 1.3.4 (updated translations) and rox-cvs 1.3.5 (based on 20021017 cvs snapshot). In this version of rox-cvs I REMOVED support for running <dir>/AppRun on (double)click on <dir> icon. There are two places in filer where <dir>/AppRu(i)n is used: - using application to set background - using <dir>/AppInfo.xml to add some menus PS This is the only version which has toolbar detachable - I removed this patch in my home version - so if someone want to look how unusable is detached toolbar then you can see it now ;) -- Marcin 'Szczepan|Hrw' Juszkiewicz mailto: marcin<at>amiga<dot>pl my Debian packages: deb http://users.stone.pl/szczepan/ apt/ |
From: Thomas L. <ta...@ec...> - 2002-10-22 15:37:00
|
On Tue, Oct 22, 2002 at 05:19:18PM +0200, Marcin Juszkiewicz wrote: [...] > In this version of rox-cvs I REMOVED support for running <dir>/AppRun on > (double)click on <dir> icon. There are two places in filer where > <dir>/AppRu(i)n is used: > > - using application to set background > - using <dir>/AppInfo.xml to add some menus - panel applets? - tutorials? - all other ROX applications? Maybe I'm missing something obvious, but what is the point in this, apart from stopping a lot of things working, and making lots of other things more difficult? Are you removing support for running all programs (eg /usr/bin/gimp), or is it just those implemented using directories that will stop working? Up to you what you do with your packages, of couse. Just curious... -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Marcin J. <ma...@am...> - 2002-10-24 15:50:13
|
On Tue, Oct 22, 2002 at 04:33:45PM +0100, Thomas Leonard wrote: > On Tue, Oct 22, 2002 at 05:19:18PM +0200, Marcin Juszkiewicz wrote: > > In this version of rox-cvs I REMOVED support for running <dir>/AppRun on > > (double)click on <dir> icon. There are two places in filer where > > <dir>/AppRu(i)n is used: > > > > - using application to set background > > - using <dir>/AppInfo.xml to add some menus > - panel applets? > - tutorials? > - all other ROX applications? "ROX applications"... I never used RiscOS (or even saw it) so idea of "<dir>/AppRun" is too strange for me and rather disturbing. ROX-Filer allows to use 'shortcuts' to applications in normal style - I can drop "/usr/bin/gimp" on pinboard, set any icon for it, rename it to "The Gimp" and use it - don't need AppRun script for it. > Maybe I'm missing something obvious, but what is the point in this, apart > from stopping a lot of things working, and making lots of other things > more difficult? > > Are you removing support for running all programs (eg /usr/bin/gimp), or > is it just those implemented using directories that will stop working? Let I wrote few words :) I used next operating systems: 1. AmigaOS 2.04/3.x 2. Microsoft Windows 3.x and all upper versions 3. Linux/XFree86 with GNOME 1.x, tried KDE 1/2/3, Enlightment 0.16 In each of those enviroments when I doubleclick on directory icon I get it open and may look what is inside. With ROX-Filer I have to wonder - will it be directory or some kind of AppRuin in it (maybe with 'nice' "rm -rf /" like thing). You will probably say something like this: "Application dirs names are marked with color so you can see is it or not with AppRun" but it still need to use menu to look inside instead of just (double)click on it. So I removed this functionality and it won't back in my rox-cvs package (maybe I will rename it to "rox-filer-hrw" so people won't get it as plain rox-filer cvs snapshot). At now I'm using ROX-Filer ONLY as a filer (and desktop manager) - as panel I use GNOME2 panel - I found it more useful then ROX one. > Up to you what you do with your packages, of couse. Just curious... I plan to keep "rox" package to be just more Debian policy friendly version of 'vanilla' ROX-Filer - it won't get any addons or removed functionality. I also plan to release it quite often then just on official releases - as you can see current version (1.3.4-3) has translations updated to versions which appear few days after release (Swedish, updated French (with doc) and Polish). Second package ("rox-cvs" at this moment - maybe it will be renamed to "rox-filer-hrw" as I wrote earlier) will get additional patches - some of them will change it to fill my needs (like more UTF8 conversions), few will add some functionality - like sortbutton.patch, ghistory.patch by Stephen Watson etc. -- Marcin 'Szczepan|Hrw' Juszkiewicz mailto: marcin<at>amiga<dot>pl my Debian packages: deb http://users.stone.pl/szczepan/ apt/ |
From: Thomas L. <ta...@ec...> - 2002-10-25 11:01:05
|
On Thu, Oct 24, 2002 at 05:49:45PM +0200, Marcin Juszkiewicz wrote: > On Tue, Oct 22, 2002 at 04:33:45PM +0100, Thomas Leonard wrote: [...] > > Are you removing support for running all programs (eg /usr/bin/gimp), or > > is it just those implemented using directories that will stop working? > > Let I wrote few words :) I used next operating systems: > > 1. AmigaOS 2.04/3.x > 2. Microsoft Windows 3.x and all upper versions > 3. Linux/XFree86 with GNOME 1.x, tried KDE 1/2/3, Enlightment 0.16 So not RISC OS, NeXT or MacOS X, then? > In each of those enviroments when I doubleclick on directory icon I get > it open and may look what is inside. With ROX-Filer I have to wonder - > will it be directory or some kind of AppRuin in it (maybe with 'nice' > "rm -rf /" like thing). You will probably say something like this: > > "Application dirs names are marked with color so you can see is it or > not with AppRun" > > but it still need to use menu to look inside instead of just > (double)click on it. So I removed this functionality and it won't back > in my rox-cvs package (maybe I will rename it to "rox-filer-hrw" so > people won't get it as plain rox-filer cvs snapshot). But this argument applies equally to all executables. Eg, when you double-click a file icon it opens in a text editor and you see what's inside. With ROX-Filer, you have to wonder - will it be executable (maybe with 'nice' "rm -rf /" like thing). Of course, you can spot this by the fact that it's coloured as an executable. As with an executable directory, you must Shift+Click to look inside. So what's the difference? If it looks like an executable, clicking on it will run it and shift+clicking will edit it. -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Marcin J. <ma...@am...> - 2002-10-25 11:27:14
|
On Fri, Oct 25, 2002 at 11:57:21AM +0100, Thomas Leonard wrote: > On Thu, Oct 24, 2002 at 05:49:45PM +0200, Marcin Juszkiewicz wrote: > > Let I wrote few words :) I used next operating systems: > So not RISC OS, NeXT or MacOS X, then? NeXT have seen working once, MacOS X - no (only MacOS 7.5/7.6/8.1). RISC OS newer. > > In each of those enviroments when I doubleclick on directory icon I > > get it open and may look what is inside. With ROX-Filer I have to > > wonder - > But this argument applies equally to all executables. Eg, when you > double-click a file icon it opens in a text editor and you see what's > inside. With ROX-Filer, you have to wonder - will it be executable > (maybe with 'nice' "rm -rf /" like thing). Of course, you can spot > this by the fact that it's coloured as an executable. As with an > executable directory, you must Shift+Click to look inside. So what's > the difference? We have other vision of using filemanager - You used RISC OS before in which some thing are done in other style then in many other enviroments, I used systems with click-to-opendir style. Idea of AppRun is too strange to me so I removed it. Unix systems maybe lack some kind of application-icon like it is in Microsoft Windows (where it can be inside of application file) or in AmigaOS (where it is in file called application.info and can have two stages - marked and nonmarked). Without it user must select icon per application, per directory (AmigaOS has icon problem resolved totally - each file can have an icon (but icon.info.info isn't an icon for icon.info but it is just a second icon). > If it looks like an executable, clicking on it will run it and > shift+clicking will edit it. and click-to-run_program is normal for nearly all users isn't it? So it is click-to-open_directory normal for non-(RISC OS|NexT|MacOS X) users. -- Marcin 'Szczepan|Hrw' Juszkiewicz mailto: marcin<at>amiga<dot>pl my Debian packages: deb http://users.stone.pl/szczepan/ apt/ |
From: Filip V. R. <mec...@de...> - 2002-10-25 11:42:49
|
On Fri, Oct 25, 2002 at 11:57:21AM +0100, Thomas Leonard wrote: > On Thu, Oct 24, 2002 at 05:49:45PM +0200, Marcin Juszkiewicz wrote: > > > > Let I wrote few words :) I used next operating systems: > > > > 1. AmigaOS 2.04/3.x > > 2. Microsoft Windows 3.x and all upper versions > > 3. Linux/XFree86 with GNOME 1.x, tried KDE 1/2/3, Enlightment 0.16 > > So not RISC OS, NeXT or MacOS X, then? Does MacOS 9 count? I'll stick to the cliché argument: I wouldn't say an OS which requires you to move an icon to a trashcan to eject a cdrom demonstrates a good design. > > In each of those enviroments when I doubleclick on directory icon I get > > it open and may look what is inside. > > But this argument applies equally to all executables. Eg, when you > double-click a file icon it opens in a text editor and you see what's > inside. With ROX-Filer, you have to wonder - will it be executable (maybe > with 'nice' "rm -rf /" like thing). Of course, you can spot this by the > fact that it's coloured as an executable. As with an executable directory, > you must Shift+Click to look inside. So what's the difference? Well, for one thing - it's (only slightly) harder to perform an rm -rf from an executable. While just about anyone can stick an AppRun with rm -rf in a directory, and claim it's program frot which is used to frot icons with (whatever that may mean :-) Second, don't look at it as installed applications. Look at an AppDir as a just extracted tarball. I want to take a look inside first before I run it. The default way to deal with it is to immediately run it. It shouldn't be. Third, I'm paranoid and I don't install binaries which are not supplied by my vendor [1]. Before I compile I want once again take a look inside the directory tree first, and even check the makefile (or equivalent). Again the default action is to immediately compile. Assume I don't mind immediate compilation, if something goes wrong I have to pull tricks again to go into the AppDir and find out what's wrong. So, I don't quite like AppDir either, as you may have noticed. Just removing it may be a bit blunt, but assuming a solution is eventually provided for the features which that breaks and which do make sense, it creates a better ROX Filer at least and ROX DE even, IMO. [2] Regards, Filip [1] not 100% true; I do own a number of Loki games. Those are the only non-vendor supplied binaries though. [2] I can't say any of the arguments called upon in favour of AppDir can convince me even without the arguments against. There are other solutions for every one of them, which fit in a lot better with the Unix style of doing things. The only true advantage is IMO the extended attributes given to applications, and those are very likely at least in Linux to come built into the filesystem in the next major kernel release. -- > I wasn't aware that BSD license was so short, i assumed it was > loong like GPL and friends. No, BSD folks got other things to do than write licences. *duck* -- Arthur Korn |
From: Filip V. R. <mec...@de...> - 2002-10-25 11:45:18
|
On Fri, Oct 25, 2002 at 01:44:35PM +0200, Filip Van Raemdonck wrote: > > Does MacOS 9 count? I'll stick to the cliché argument: I wouldn't say an > OS which requires you to move an icon to a trashcan to eject a cdrom > demonstrates a good design. Hmm, I'd want to add that this doesn't mean there are no good things to be taken from them. AppDir isn't just one of them for me. Regards, Filip -- "The only way to get rid of a temptation is to yield to it." -- Oscar Wilde |
From: Thomas L. <ta...@ec...> - 2002-10-25 13:14:46
|
On Fri, Oct 25, 2002 at 01:44:35PM +0200, Filip Van Raemdonck wrote: > On Fri, Oct 25, 2002 at 11:57:21AM +0100, Thomas Leonard wrote: [...] > > But this argument applies equally to all executables. Eg, when you > > double-click a file icon it opens in a text editor and you see what's > > inside. With ROX-Filer, you have to wonder - will it be executable (maybe > > with 'nice' "rm -rf /" like thing). Of course, you can spot this by the > > fact that it's coloured as an executable. As with an executable directory, > > you must Shift+Click to look inside. So what's the difference? > > Well, for one thing - it's (only slightly) harder to perform an rm -rf > from an executable. What? It's harder to create an executable that does 'rm -rf' than an app dir which does the same? How? For one thing, the action is implemented using an executable inside the directory anyway! > While just about anyone can stick an AppRun with rm -rf in a directory, > and claim it's program frot which is used to frot icons with (whatever > that may mean :-) You can only put an AppRun in a directory which you own. And you can name an executable anything you like (eg, 'gimp'). Again, no difference. > Second, don't look at it as installed applications. Look at an AppDir as > a just extracted tarball. I want to take a look inside first before I > run it. The default way to deal with it is to immediately run it. It > shouldn't be. But if you extract a tarball, then look inside, the default action for the 'configure' script is also to run it, not to edit it (and this is the same as other filers). So you still have to know to press Shift (or use the menu). > Third, I'm paranoid and I don't install binaries which are not supplied > by my vendor [1]. You still have to apt-get source before installing any debs, though, or you'll get hit by numerous problems (was it last week Debian users could log in as 'mail' without a password?). If you want to be paranoid, you need to provide security by the kernel, only providing exactly the access needed on an application-by-application basis. NOT by making it easier for users to audit code by setting it up so they only have to press Shift once instead of twice to see the code. > Before I compile I want once again take a look inside the directory tree > first, and even check the makefile (or equivalent). Again the default > action is to immediately compile. > Assume I don't mind immediate compilation, if something goes wrong I > have to pull tricks again to go into the AppDir and find out what's > wrong. Again, the 'trick' is exactly the same as the 'trick' needed to edit any executable. > [2] I can't say any of the arguments called upon in favour of AppDir can > convince me even without the arguments against. There are other > solutions for every one of them, which fit in a lot better with the > Unix style of doing things. > The only true advantage is IMO the extended attributes given to > applications, and those are very likely at least in Linux to come > built into the filesystem in the next major kernel release. So, if I distribute an application as a single python script, using extended attributes to give it an icon and tooltip, you'll be perfectly happy with that? Even though it's exactly equivalent to what we have now? -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Filip V. R. <mec...@de...> - 2002-10-25 21:02:51
|
On Fri, Oct 25, 2002 at 02:11:00PM +0100, Thomas Leonard wrote: > On Fri, Oct 25, 2002 at 01:44:35PM +0200, Filip Van Raemdonck wrote: > > > > Well, for one thing - it's (only slightly) harder to perform an rm -rf > > from an executable. > > What? It's harder to create an executable that does 'rm -rf' than an app > dir which does the same? How? For one thing, the action is implemented > using an executable inside the directory anyway! My mistake, I meant binary vs AppRun shell script. Off course a perl or python script is a different matter altogether. > > While just about anyone can stick an AppRun with rm -rf in a directory, > > and claim it's program frot which is used to frot icons with (whatever > > that may mean :-) > > You can only put an AppRun in a directory which you own. And you can name > an executable anything you like (eg, 'gimp'). Again, no difference. That's after it's on the system. What I meant was someone can grab an existing application, make an AppDir wrapper which does Nasty Things around it and start distributing. Yes, he's likely to get caught fairly soon, etc. etc. But he will get away with it for even a short while and some people will get burnt and AppDir is making it both easier for the attacker to do this *and* lowering the barrier for the user to fall into the pit. Before you comment on this, read further. > > Before I compile I want once again take a look inside the directory tree > > first, and even check the makefile (or equivalent). Again the default > > action is to immediately compile. > > Assume I don't mind immediate compilation, if something goes wrong I > > have to pull tricks again to go into the AppDir and find out what's > > wrong. > > Again, the 'trick' is exactly the same as the 'trick' needed to edit any > executable. Well, this time it's not because we're not talking executables anymore - it's about failing compilation. That's a makefile to check, or a config.log. > > [2] I can't say any of the arguments called upon in favour of AppDir can > > convince me even without the arguments against. There are other > > solutions for every one of them, which fit in a lot better with the > > Unix style of doing things. > > The only true advantage is IMO the extended attributes given to > > applications, and those are very likely at least in Linux to come > > built into the filesystem in the next major kernel release. > > So, if I distribute an application as a single python script, using > extended attributes to give it an icon and tooltip, you'll be perfectly > happy with that? Even though it's exactly equivalent to what we have now? No I wouldn't. But IMO AppDir is a kludge to fix things for which other solutions are available. It doesn't provide any real advantages over those others; and rather some disadvantages - even if only "it works different than other file managers", if you don't agree with the points I was trying to make. Granted, neither of my arguments are very strong. But instead of asking, "why remove it", ask "why add it in the first place", turning the whole discussion around. And then I believe you won't be able to make a compelling point in favour just as I cannot make a compelling point against (what I mentioned are issues, but only slight ones as you pointed out. I was and am very much aware of that). The best answer to "why add it" would be (aside from the attibutes) "because we can, and because we like it". Similarly, the answer to your "why remove it" is "because I can, and didn't like it in the first place" (and that seems to hold true for others, too) I didn't mean to get into this discussion. I've rolled my own packages for about a year now, and removing AppDir was something I did on the first build. I wasn't planning on distributing them as "ROX" without a big label anyway, and more likely on not distributing them as ROX at all but rather something different (with a prominent ROX ad left in). I don't care about convincing you to remove it, I never even thought it would be a possibility. And especially not now :-) Regards Filip -- The Unixverse ends on Tue, 19 Jan 2038 03:14:07 +0000 |
From: George De B. <Sou...@my...> - 2002-10-28 06:05:12
|
On Fri, 25 Oct 2002 23:04:41 +0200 Filip Van Raemdonck <mec...@de...> wrote: > That's after it's on the system. What I meant was someone can grab an > existing application, make an AppDir wrapper which does Nasty Things > around it and start distributing. That's a thoroughly bad argument. What's to stop someone from distributing a configure script or make file that does an 'rm -f'? > Yes, he's likely to get caught fairly soon, etc. etc. But he will get > away with it for even a short while and some people will get burnt and > AppDir is making it both easier for the attacker to do this *and* > lowering the barrier for the user to fall into the pit. It's no easier. You are basically assuming that the AppDir is put toghether by an unreliable source. Based on that logic you have to assume that all applications that you download, no matter how they are packaged, are unreliable and go in and look at the configure and make files for all of them, or look at how the .deb or .rpm is built to ensure that it isn't going to do something nasty to your system. Do you do this for every single application that you install? > > Again, the 'trick' is exactly the same as the 'trick' needed to edit any > > executable. > > Well, this time it's not because we're not talking executables anymore - > it's about failing compilation. That's a makefile to check, or a > config.log. Again, that isn't true -- read above comment on packaging and think about it. Are you that suspicious of _everything_ that you download and install on your system? > Granted, neither of my arguments are very strong. But instead of asking, > "why remove it", ask "why add it in the first place", turning the whole Why add it? Well, quite simply: (a) it simplifies the installation process for applications, (b) it provides a unique extension to the object heirarchies that these systems have, (c) it is a method of actually simplifying system maintenance. Yes, I really mean that last item. Consider the environment in which I work. Our IT department maintains around 1,500 applications for use across our base of about 15,000 installed systems. Because of the variety of configurations in use it was necessary to wrap those 1,500 applications with scripts to detect the system configurations. Under windows, this process was an extreme mess. The whole thing had three different tree structures to maintain the scripts and resources (links, icons, shortcuts, etc.). Admittedly, at the time it was put together it was a great idea (it pre-dated RoX by several years). However, I am convinced that RoX could have simplified the whole mess into a single directory structure with a single link to the directory tree on the users desktop. Updates would then have been as simple as pushing a single script update to the server, and letting the change replicate across the mirror servers. Now, if it were possible to re-package some of the actual applications in the AppDir method (which I am certain it would have been), then a good portion of the actual application maintenance itself becomes simplified, which would have allow the IT support personnel to focus on the "problem children" applications, instead of having to maintain a portion of their efforts on the standard applications. So, yes, the AppDir concept is a win-win-win in many ways. The ramifications and ideas of it have not even begun to be explored. > The best answer to "why add it" would be (aside from the attibutes) > "because we can, and because we like it". Similarly, the answer to your > "why remove it" is "because I can, and didn't like it in the first > place" (and that seems to hold true for others, too) Was my argument above compelling enough for you? :) > I didn't mean to get into this discussion. I've rolled my own packages I was initially going to keep my comments off the list, just for you and Marcin, but seeing as the thread dragged on a bit, I felt it appropriate to post these messages to the list. // George |
From: Jan W. <ja...@ea...> - 2002-10-28 16:08:06
|
George De Bruin <Sou...@my...> schreef: [AppDir] > Why add it? Well, quite simply: (a) it simplifies the installation > process for applications, Only if you are speaking about simple applications ;-) Suppose someone writes a complex program, that depends on various libraries. I don't see how someone can easily install this program by making use of the AppDir-method. Offcourse, it is possible to install this program as a normal user in an AppDir, but you still need to be root to install the necessary libraries. -- Met vriendelijke groetjes - Jan Wagemakers - ... movl $1, %eax ; movl $0, %ebx ; int $0x80 |
From: Stephen W. <wa...@ul...> - 2002-10-28 16:34:48
|
In message <200...@qw...> Jan Wagemakers <ja...@ea...> scribbled: > George De Bruin <Sou...@my...> schreef: > > [AppDir] > > Why add it? Well, quite simply: (a) it simplifies the installation > > process for applications, > > Only if you are speaking about simple applications ;-) > > Suppose someone writes a complex program, that depends on various > libraries. I don't see how someone can easily install this program by > making use of the AppDir-method. Offcourse, it is possible to install this > program as a normal user in an AppDir, but you still need to be root to > install the necessary libraries. ROX-CLib was an attempt to prove you could use AppDir's for libraries as well as Apps. Without root permission you install ROX-Clib in ~/lib then you can build and run Clock and FreeFS quite happily. -- Stephen Watson Physicist Ultra Electronics Ltd - Signature Management Systems (UESMS) Tel: +44 (0)1543 878888 (switchboard) Fax: +44 (0)1543 878249 Email: wa...@ul... |
From: Thomas L. <ta...@ec...> - 2002-10-28 16:55:11
|
On Mon, Oct 28, 2002 at 05:08:00PM +0100, Jan Wagemakers wrote: > George De Bruin <Sou...@my...> schreef: > > [AppDir] > > Why add it? Well, quite simply: (a) it simplifies the installation > > process for applications, > > Only if you are speaking about simple applications ;-) Isn't the Mac version of MS Office supplied as an app dir? -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Leandro A. F. P. <le...@li...> - 2002-10-28 23:36:44
|
On Mon, 28 Oct 2002 16:51:03 +0000 Thomas Leonard <ta...@ec...> wrote: > > > > Only if you are speaking about simple applications ;-) > > > > Isn't the Mac version of MS Office supplied as an app dir? > Yes. And you can run it from the CD. -- Leandro Pereira (oO) <le...@li...> www.mindcrisis.tk /||\ GPG key: 0x062E7976 "Alguns homens vêem as coisas como são, e dizem 'Por quê?' Eu sonho com as coisas que nunca foram e digo 'Por que não?'" --George Bernard Shaw . |
From: Jan W. <ja...@ea...> - 2002-10-29 15:39:57
|
Thomas Leonard <ta...@ec...> schreef: >> [AppDir] >>> Why add it? Well, quite simply: (a) it simplifies the installation >>> process for applications, >> Only if you are speaking about simple applications ;-) > Isn't the Mac version of MS Office supplied as an app dir? Mmm, reading the various replies, I have probably misunderstood some things about AppDir's... But I was wondering, how do you see these AppDir's? Do you see it as a substitute for systems like rpm or deb (apt-get). If yes, how do we handle things like dependencies? If no, which programs should come as an AppDir and which programs should be installed the 'normal' way? -- Met vriendelijke groetjes - Jan Wagemakers - ... Linux inside |
From: Larry C. <lar...@fr...> - 2002-10-29 15:47:30
|
On Tue, 29 Oct 2002 16:39:50 +0100 Jan Wagemakers <ja...@ea...> wrote: > But I was wondering, how do you see these AppDir's? Do you see it as a > substitute for systems like rpm or deb (apt-get). If yes, how do we > handle things like dependencies? If no, which programs should come as > an AppDir and which programs should be installed the 'normal' way? According to me, "end-user" programs should be AppDir-ized, while "system" programs (or libs) shouldn't change. The problem is when dealing with end-user apps that are also dependancies to other programs. Bonobo apps, for exemple... An idea for these ones? |
From: Thomas L. <ta...@ec...> - 2002-10-29 15:52:39
|
On Tue, Oct 29, 2002 at 04:39:50PM +0100, Jan Wagemakers wrote: > Thomas Leonard <ta...@ec...> schreef: > > >> [AppDir] > >>> Why add it? Well, quite simply: (a) it simplifies the installation > >>> process for applications, > >> Only if you are speaking about simple applications ;-) > > Isn't the Mac version of MS Office supplied as an app dir? > > Mmm, reading the various replies, I have probably misunderstood some things > about AppDir's... > > But I was wondering, how do you see these AppDir's? Do you see it as a > substitute for systems like rpm or deb (apt-get). If yes, how do we handle > things like dependencies? If no, which programs should come as an AppDir > and which programs should be installed the 'normal' way? Well, I generally see package management and app dirs as things that work well in parallel. Of course, some people like to do things themselves (eg, with Linux From Scratch). App dirs do make that easier. But a system like Debian offers many other advantages (testing, bug tracking, dependancy analysis, consistancy, etc). The argument that because we have package management there's no need to lay things out clearly doesn't make much sense. Even if everything is installed automatically, I still have to look at the filesystem, and it would be nice to have something fairly presentable. On RISC OS, you'd be happy to show your root directory to your mum, because things were organised clearly into high-level categories (Applications, System, Boot, etc). I think a good analogy is with a library, wondering whether to organise books by group (app dirs) or store locations on a computer (package management). The best solution is to do both... -- Thomas Leonard http://rox.sourceforge.net ta...@ec... ta...@us... GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
From: Marcin J. <ma...@am...> - 2002-10-29 16:27:28
|
On Tue, Oct 29, 2002 at 03:48:22PM +0000, Thomas Leonard wrote: > Well, I generally see package management and app dirs as things that work > well in parallel. Of course, some people like to do things themselves (eg, > with Linux From Scratch). App dirs do make that easier. But a system like > Debian offers many other advantages (testing, bug tracking, dependancy > analysis, consistancy, etc). You have right - Appdirs are quite good for simple programs which don't need to install libraries used by other programs (like libpng but you have it working with ROX-(C)Lib). At my system nearly all programs are packaged (system data are packages too -> hrw-ttf, mplayer-win32 etc). But your idea of Appdirs reminds me time when I was using AmigaOS - in that system you can have application with all it data in it directory or have his libs/commands installed in system dirs. > On RISC OS, you'd be happy to show your root directory to your mum, > because things were organised clearly into high-level categories > (Applications, System, Boot, etc). I'm kind of user who don't show filesystem to anyone - if you want to use system then you have needed applications in menu (panel menu, window-manager menu etc). BTW - is there any possibility to have ROX-Filer showing user menu on mouseclick? BTW2 - I'm thinking about adding "help" parameter to AppInfo.xml file - not always program has a help files in Help/ dir - it also can have them system wide installed in /usr/share/doc/programname (I know - it can be symlinked) -- Marcin 'Szczepan|Hrw' Juszkiewicz mailto: marcin<at>amiga<dot>pl my Debian packages: deb http://users.stone.pl/szczepan/ apt/ |
From: Robert D. <rob...@ha...> - 2002-10-31 23:49:04
|
29/10/2002 16:27:17, Marcin Juszkiewicz <ma...@am...> wrote: >> On RISC OS, you'd be happy to show your root directory to your mum, >> because things were organised clearly into high-level categories >> (Applications, System, Boot, etc). > > I'm kind of user who don't show filesystem to anyone - if you want to >use system then you have needed applications in menu (panel menu, >window-manager menu etc). But this is one of the main advantages of App Dirs. With a complicated filesystem, typical to UNIX, in order to find and launch applications from the desktop, you need some form of application launcher (root menu, 'start' or launch button etc.). With App Dirs, like in RISC OS, your filer becomes your application launcher as well as your file manager. A user only ever has to learn one paradigm. Additionally, they can understand if they delete the application icon from the filer (in exactly the same way as deleting a file) it removes the application from the system (as you are deleting the complete App Dir). With the typical paradigm used by Windows and most UNIX desktops, you have a file-manager, an application launcher, another view of the filer from the load/save dialogues, and another add/remove programs or package manager. With RISC OS or ROX, you have the filer to do this all. Simple. (And yes, I know this simplistic argument ignores dependencies on or between libraries and so forth). |
From: Robert D. <rob...@ha...> - 2002-10-31 23:49:19
|
This talk of library dependency issues with App Dirs has led me to remember how RISC OS used to handle this. It had no install-time dependency checks (that I can remember) but just used to check dependencies at run time with RMEnsure (or something similar, from memory). Would it be possible to write something similar into the AppRun script for ROX? So it would give a sane error message if required libraries are not found, rather than just probably seg faulting? This could be useful in an environment where you are running an AppDir without actually having it locally on your system, such as from a network share. Whoever publishes the application to the share, may not be able to guarantee every client that tries to run it has the correct libraries. So if this can be checked every time the user runs the application, it would at least tell them what was wrong. I don't know how this might be achieved under UNIX, as libraries can be installed all over the place. But it seems that the make files have a mechanism for seeing if the required libraries are present at compile-time. Perhaps something similar could be implemented for run-time dependencies as an 'AppDep' script that runs before AppRun? Just a thought anyway. |
From: George De B. <Sou...@my...> - 2002-11-01 15:59:53
|
On Wed, 30 Oct 2002 12:00:18 -0000 Robert Davison <rob...@ha...> wrote: > This talk of library dependency issues with App Dirs has led me to > remember how RISC OS used to handle this. It had no install-time Hi Robert, This is one of the things that I have been thinking about too. Unfortunately, I think that for a truely well thought out and workable solution, we need a completely different mechanism...which I don't forsee the Unix / Linux communities bending to... Basically, what I am thinking is something along this line: - First, it would be necessary for there to be centralized locations for installing libraries. Something similar to the way that applications (especially in Rox's model) currently look for MIME information (app->home->local->global), being able to stop after the item is found. For example, this might give a path of something like: ./:~/lib:/usr/share/local/lib:/usr/share/lib (Note: "./" refers to the AppDir here, not to the actual current working directory.) - Second, for an application to enable the possibility of allowing the library to be removed with the application, use symlinks in the AppDir to point directly to shared libraries. When the application is removed, Rox could look at the link count on the target library to determine if there are other applications or libraries that depend on it. If there aren't, then the library can be safely removed. As a side note: this adds something additional that is rather nice. An application itself can declare it's own depencies on a library. Even if it isn't necessary for it to symlink itself to a library, it can in the case that it is decided that it will always desirable to have that library in place. That decision could be left up to the user -- it would be a way for the user to declare that specific features or mechanisms should be left in place, even if they aren't absolutely necessary. The one trick to this would come in upgrading libraries. It would likely be useful to have a mechanism to trace the symlinks backwards: from library to application. Even better would be a mechanism to tell the installer what it requires from the library, which could be used to determine if a libraries upgrade would be transparent to the application, and therefore just require re-directing the symlink to the new library. If it wouldn't be transparent, then the original library could be maintained, and the new library installed alongside the original (assuming that the two wouldn't directly collide). (Another aside: Hmnm, the more I think about this, the more I think that an analogue to the AppDir concept -- may called LibDir -- might be a good way to encapsulte these ideas. Libraries could be installed in LibDirs, the LibDirs could use something similar to AppRun files / links to provide all the needed wrapping functionality. And, the applications would link to the LibDir(s) for groups of libraries, instead of to individual library files... This idea needs some more thought.) As I said above, unfortunately, a mechanism that would be this sophisticated (and offer a generally optmized search method) would realy require that the whole OS follow it as a general model. Although, I wonder if something like this might be a good way to extend the development model for Rox specific applications? (The concept LibDirs is only half hatched, so there would need to be a lot of work on that, but the idea of using symlinks to libraries, and a library search path would probably work out well...) // George |
From: Filip V. R. <mec...@de...> - 2002-11-03 11:34:32
|
On Fri, Nov 01, 2002 at 09:49:17AM -0600, George De Bruin wrote: > > - First, it would be necessary for there to be centralized locations > for installing libraries. Something similar to the way that > applications (especially in Rox's model) currently look for MIME > information (app->home->local->global), being able to stop after the item > is found. For example, this might give a path of something like: > ./:~/lib:/usr/share/local/lib:/usr/share/lib (Note: "./" refers to > the AppDir here, not to the actual current working directory.) How is this different from LD_LIBRARY_PATH? Am I missing something? > - Second, for an application to enable the possibility of allowing the > library to be removed with the application, use symlinks in the AppDir > to point directly to shared libraries. When the application is > removed, Rox could look at the link count on the target library to > determine if there are other applications or libraries that depend on > it. If there aren't, then the library can be safely removed. You can't do this with symlinks, they don't keep link counts. You need hardlinks for that. And those are limited to the same filesystem where the original is on (which is a vague term, because the original is really the data inodes and all hardlink vfs paths are equals), so network mounts or different mount points for /home and /usr for example can't use this. Which makes the whole point moot. Also, I think link count is a terrible idea of deciding whether a library should be kept on the system or not. When it gets removed, the next time you install an application which needs it that app won't work. I know you (and others on this list) and I disagree on this, but this is exactly where package managers are until this date unsurpassed by any other installation mechanism. They can tell you if a library package has no dependencies left, and you can decide to remove it, and it'll tell you when a new package you want to install needs a library. (Whether the mechanisms of hunting down dependencies suck in certain package managers' implementation suck are an unrelated matter :-) > Even better would be a mechanism to tell > the installer what it requires from the library, which could be used > to determine if a libraries upgrade would be transparent to the > application, and therefore just require re-directing the symlink to > the new library. If it wouldn't be transparent, then the original > library could be maintained, and the new library installed alongside > the original (assuming that the two wouldn't directly collide). The coexistence and picking the right version of a library is already handled by the current dynamic linkers and sonames and soversions. They don't check the applications, but again a package manager helps a whole lot there :p Regards, Filip -- "Unix is simple. It just takes a genius to understand its simplicity." -- Dennis Ritchie |
From: George De B. <Sou...@my...> - 2002-11-04 18:16:32
|
On Sun, 3 Nov 2002 12:37:18 +0100 Filip Van Raemdonck <mec...@de...> wrote: > On Fri, Nov 01, 2002 at 09:49:17AM -0600, George De Bruin wrote: > > > > - First, it would be necessary for there to be centralized locations > > for installing libraries. Something similar to the way that > > applications (especially in Rox's model) currently look for MIME > > information (app->home->local->global), being able to stop after the item > > is found. For example, this might give a path of something like: > > ./:~/lib:/usr/share/local/lib:/usr/share/lib (Note: "./" refers to > > the AppDir here, not to the actual current working directory.) > > How is this different from LD_LIBRARY_PATH? Am I missing something? How would LD_LIBRARY_PATH be able to know the AppDir that an application is launching from? Also (as mentioned below) the idea of using something like a LibDir wouldn't be (easily) supported using LD_LIBRARY_PATH. > You can't do this with symlinks, they don't keep link counts. You need > hardlinks for that. And those are limited to the same filesystem where Rats. That's what I get for writing stuff at four or five in the morning, and not double checking myself. I had them backwards in my mind. And yes, I agree that hardlinks would too restrictive. > Also, I think link count is a terrible idea of deciding whether a > library should be kept on the system or not. When it gets removed, the > next time you install an application which needs it that app won't work. You and I disagree here. Any time you simplify dependencies it is better for the system. Removing items that aren't in use makes sense as a step in simplification and reducing overhead. If a mechnism existed for the library to tell the system wether it's in use or not then resource management could be simplified. It appears (to me at least) a more elegant solution. > I know you (and others on this list) and I disagree on this, but this is > exactly where package managers are until this date unsurpassed by any > other installation mechanism. They can tell you if a library package has > no dependencies left, and you can decide to remove it, and it'll tell > you when a new package you want to install needs a library. (Whether the > mechanisms of hunting down dependencies suck in certain package managers' > implementation suck are an unrelated matter :-) Umm, I would say it is exactly the point of the discussion. If you can't rely on the dependency handling of the package manager (and I have yet to see a package manager that I thought was completely reliable), then looking at alternatives makes sense. And, alternatives can and should offer something that might help with things (thus the idea of reducing the resources needed). > The coexistence and picking the right version of a library is already > handled by the current dynamic linkers and sonames and soversions. > They don't check the applications, but again a package manager helps a > whole lot there :p Which brings us back to the point of: if current package managers were reliable this probably wouldn't be an issue. (Although, I could always wish they actually worked better...<g>) Anyway - this was just an idea off the top of my head. Not something that I thought Thomas would want to rush out and implement. Just an idea to float around in case there was any specific interest. :) // George |
From: Lemmit K. <le...@ka...> - 2002-11-04 19:39:59
|
Hi, making Linux library system more friendly is a really interesting subject that I have pondered over a lot. Unfortunately I have come to the conclusion that such a system cannot be built on top of any existing distributions. Therefore I have had vague ideas of working out Yet Another Linux Distribution just for such purpose. If anyone here is remotely interested, I welcome you to contact me. Not that I have anything done, but we could share ideas and let the wonderful ROX project use its mailinglist for ROX related talk. The best, L. > > > - First, it would be necessary for there to be centralized > locations |