Re: My ideas on LSB
On Tue, 21 Mar 2000 firstname.lastname@example.org 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.
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
evan leibovitch <email@example.com> starnix inc.
tollfree: 1-87-pro-linux brampton, ontario, canada
http://www.starnix.com professional linux services & products