Gabriel M. Beddingfield wrote: > But, if I supply extra applications/packages with my > device... things that are core to my OEM product... > is it OK to package them according to LSB? Obviously, > all the packages in MeeGo Core have been installed using LSB.
Yes, and no. For things you add on as a device builder you can choose; the idea of the FHS filesystem namespace rules (which are imported into LSB and slightly expanded there because FHS is OS-agnostic and misses some Linux conventions as a result) is the separate three roles and keep them from stepping on each other with their installs - (1) OS vendor, (2) ISV, (3) local system operator/administrator/owner, whichever term fits. As a device builder you're perhaps some of (1) and (2) both, and you can make sure to avoid conflicts. On the other hand, there's no particular /need/ for the core or profile pieces to follow the addon paths, because they are firmly in category (1). > Operating system standard locations: > > If I'm writing an app that, for instance, lists all > the applications installed (*.desktop)... where do > I go to find these? According to this, I would need > to `find /opt -name "*.desktop"`, and there's > no mention of /usr/share/applications or an LSB spec. > > What I'm getting at (to be a little more clear) is > that when an application NEEDS something from the > OS, this spec doesn't provide any information about > where to go. Right now, reference to LSB is limited > to application binary format (ELF).[1] It might be > good to appeal to more of the LSB Core[2] and even LSB Desktop.[3] some of that will perhaps happen but LSB, which itself refers to several other docs, is a smaller set than MeeGo Core and too many levels of reference means nobody will bother to follow the references - I'm working on the idea that this spec ought to be a relatively complete description of what people need. Without becoming a 1000-page doc, that is! :) All that subject to adjustment as things evolve, I guess. _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev