On Tue, 21 Mar 2000 [EMAIL PROTECTED] wrote: > Linux has no standard component location organization. Such a situation > makes it difficult for 3rd party software vendors to make installation > scripts and know where to put program components. Hey! We've got FHS > so this is mostly done. > > Exactly.
But this job isn't complete. Third-party developers need more guidance beyond the FHS, since that spec still allows a number of options. The LSB needs to recommend a default, while allowing that any FHS-compliant placement is OK. > Linux has no stadardized program installation method. This is a minor > problem but one, that if addressed in a competant manner, will make it > easier for users and ISVs alike. > > The current plans of the LSB is to provide a standard package format > (currently RPM), and a standard command-line installation tool which can > be executed by the user to install an LSB application. Will the LSB tighten the RPM spec so that we don't have the kind of compatibility problems we have now (ie, a Red Hat RPM won't necessarily be installable on a Caldera system, a SuSE RPM won't install on Turbo, etc.)? I've seen significant developer frustration over this one. If that's not dealt with, then we have a problem -- someone building an LSB-compliant app would still be able to produce an RPM package that won't install on all LSB-compliant distros, in which case the value of the standard diminishes significantly. Most sources of such RPM compatibility problems (ie, are spec files case-sensitive) should be easy to fix, but they can't be ignored. Will LSB develop a standard dependency naming scheme for what it deems to be base components? Or will an LSB compliant app look for an "LSB" in the RPM database? -- evan leibovitch <[EMAIL PROTECTED]> starnix inc. tollfree: 1-87-pro-linux brampton, ontario, canada http://www.starnix.com professional linux services & products
