On Tue, 18 Nov 2003 16:32:26 +0100 Götz Waschk <[EMAIL PROTECTED]> wrote:
> Am Dienstag, 18. November 2003, 16:27:37 Uhr MET, schrieb Marcel Pol: > > > apps can be arch dependent and since /usr could be shared by NFS, menu > > > entries should be in /usr/lib.. (well, it was Debian rationale for > > > menu location..) > > But the menufiles are arch-independent. > > The menu files are arch-independant, but the application in the menu > entry can be architecture-dependant. Imagine a menu entry for vmware, > that wouldn't make sense on the Linux/PPC machine. True, but I would call that an exception. Most apps in the menu are available on different architectures. That doesn't count for the libraryfiles of them, .so files are all arch dependent. The menufile can still be used on Linux/PPC, it can still generate a menu, nothing will crash, while you cannot load a .so file for x86 on ppc. The menufile will be useless though, because there's no package that comes with it. > > I assume it will be fixed when we switch to the freedesktop menufiles > > proposal. It doesn't list the place for these files however, but it seems > > a lot like the kde/gnome desktop files that are in /usr/share/app*. > So the architecture-dependance of the menu files will be lost? They use a different approach. http://freedesktop.org/Standards/desktop-entry-spec/desktop-entry-spec-0.9.4.html There is a key TryExec: "A list of regular expressions to match against for a file manager to determine if this entry's icon should be displayed. Usually simply the name of the main executable and friends." So if vmware is not installed on Linux/PPC, it will not be part of the menu. -- Marcel Pol
