[lsb-discuss] LSB adoption acceleration proposal

[Ian Murdock]

(Weighing in a bit late, but I'm WAY behind on my email.)

On 9/29/06, Lepied, Frederic <frederic.lepied at intel.com> wrote:
> Hi,
>
> To accelerate the adoption of the LSB, we should promote its use
> inside the open source community. This would demonstrate that the LSB
> is viable solution with real life examples of how to implement it.
>
> The idea is to help projects that are already building binary packages
> for some distros to build binary packages for the LSB instead. We
> could then imagine to advertize such projects or to list them
> somewhere on the LSB web pages.
>
> If some of you are interested, we could form a group to help open source
> projects adopt the LSB.
>
> WDYT ?

FWIW, this is very much something we've had in mind, though I'm not
sure we're ready to pursue it yet from a tools point of view.

The basic idea is this: Position the LSB as a practical solution to a
common problem. For ISVs, that common problem is how to distribute their
software in binary form without resorting to shipping numerous distro
specific packages or ad-hoc, self-extracting installers that integrate
poorly if at all with the underlying operating system (or simply not
shipping their software in binary form at all for Linux). For end users,
the common problem is consistent access to upstream binaries in a way
that integrates well (no postinstall scripts that create symlinks outside
the package system, self created symlinks, direct alien invocations,
etc.). (Note: "Integrates well" means APT on
Debian systems at least, probably yum on Red Hat/SUSE/etc. as well.)

As everyone who follows the LSB has probably seen by now, one of our top
priorities right now is better tools. From an application point of view,
the tools strategy has two pillars:

1. The SDK. Bundle everything an application developer needs to build a
portable Linux application using the LSB. Right now, the SDK makes
it easy to create an LSB compliant *binary*, but doesn't yet make it
easy enough to create a distributable, easy to install
*application* (I'm avoiding the term "package" here, intentionally).

2. The Application Testkit. Provide an easy to use tool to analyze
an exciting application and determine where the application is not LSB
compliant and what to change to make it compliant; also shipped as part of
the SDK but made available as a separate lightweight download as well.

I like to think of the testkit as the LSB's validator.w3.org--an extremely
lightweight tool that makes it very simple for developers to check
their applications for standards compliance, where "lightweight"
is the key to ingraining the tool into the developer consciousness.

More details on each of these in a separate message later today. For
now, I just wanted to weigh in that we're very much thinking about
this as a strategy, and when the time comes, we could use the help to
advocate the LSB as a practical solution to the issues above. The
tools aren't quite ready yet, but the plan is to have all the tools
in place that we need to execute on this plan by early next year.

-ian
-- 
Ian Murdock
317-863-2590
http://ianmurdock.com/

"Don't look back--something might be gaining on you." --Satchel Paige