On 18/09/2011, at 9:53 PM, Thiago Macieira wrote: > On Sunday, 18 de September de 2011 13:19:53 David Faure wrote: >> Right. So would NAME=Qt be enough, or would that still lead to too many >> clash risks, between qt apps/frameworks? I guess there could be a >> QStringList QStandardPaths::libExecPaths(const QString &packageName = >> QString()) >> (whose result could be passed as argument to findExecutable), but that seems >> slightly overkill to me (compared to simply finding libexec binaries inside >> findExecutable, without a specific API for it). > > /usr/libexec/OrganisationName/ApplicationName > just like /usr/share/OrganisationName/ApplicationName
If the application is provided as part of the linux distribution, then those would be fine. If not, then the LSB recommends /opt instead of /usr and it also recommends a similar structure below /opt. The LSB recommends (requires?) conformant packages to be installed into their own private area, distinguished by either a LANANA name or your company's domain (if you are an individual and not a company, your options are not so clearly defined!). Thus, the base of your package or suite of packages might be something like one of these: /opt/kde.org /opt/kde4 The latter would only be valid if kde4 was a registered LANANA name. Below this base directory, you can use whatever directory structure you want. A recommended approach is to give each application package below this point its own subdirectory, such as: /opt/kde4/konqueror /opt/kde4/kmail This gives each application its own private area, but at a known relative position to other packages in the suite. And this is where this structure helps you in this discussion thread. If you are looking for some kde helper app, it should be at a known relative location to the current executable. This should be true for any app that is notionally part of the same suite (ie from the same "company", or in the examples used here, the same KDE installation). Where a package is included directly in /usr by a distribution, it should still obey this arrangement of keeping all the components relative to each other if that's what the package requires. Unfortunately, under unix people have generally become so accustomed to dumping binaries directly in /usr/bin and libraries in /usr/lib (or /usr/lib64), this idea of giving apps their own base directory probably feels foreign (but it is exactly what Mac and Windows do). So my suggestion would be to assume that your application suite has some common base and then make your searches for helper binaries that come as part of that suite search those relative locations, then fall back to the relevant environment variable depending on what you are looking for (PATH or LD_LIBRARY_PATH). It's not perfect, but I don't think you'll find a way that works in all cases and at least this approach (a) follows LSB-recommended practices, and (b) should teach developers better habits. I suspect that distribution maintainers won't appreciate having app developers dictate directory structure like this though. -- Dr Craig Scott Computational Software Engineering Team Leader, CSIRO (CMIS) Melbourne, Australia _______________________________________________ Qt5-feedback mailing list [email protected] http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
