[devel] [jbj@JBJ.ORG: RFC: LSB standardization via "boundary package".]

[devel] [jbj@JBJ.ORG: RFC: LSB standardization via "boundary package".]

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 4243 bytes --]

----- Forwarded message from Jeff Johnson <jbj@JBJ.ORG> -----

Date: Thu, 3 May 2001 13:59:41 -0400
From: Jeff Johnson <jbj@JBJ.ORG>
To: rpm-list@redhat.com
Subject: RFC: LSB standardization via "boundary package".
Mail-Followup-To: rpm-list@redhat.com
X-Mailer: Mutt 0.95.4us
Reply-To: rpm-list@redhat.com

As part of trying to understand the impact of LSB standardization on
distribution packaging, I've bundled up some of the components that
may/will be used to test LSB compliance, and am making a package available
for comment. Before attempting to describe what's in that package,
I need to define a few terms:

	ISV	-- the usual meaning, but, in this context, a
		"vendor-of-the-requires", i.e. a software vendor
		who wishes to produce package(s) that have a reasonable
		chance of installing perfectly on all Linux platforms.

	DSV	-- a "distribution software vendor", and, in this context,
		a "vendor-of-the-provides", i.e. a distribution vendor
		who supplies software that can be used as a build platform
		by ISV's.

	boundary package(s) -- a set of package(s), possibly a single package,
		that can be added to a distribution to establish the mapping
		dependencies between ISV's and DSV's.

Here's a brief (and simplistic) example illustrating what the needs and goals
of an ISV, a DSV, and LSB and how the needs/goals start to intersect and
overlap:

1) An ISV does not want to be bothered with the specifics of various flavors
of Linux, but wishes some assurance that the platform supples necessary
capabilities. A simple (rpm specific) packaging rule to achieve that goal
might be to hide all the flavors behind a single dependency:

	Requires: LSB

2) A DSV needs to be able to change distro dependencies for all sorts of
reasons, but wishes to provide a stable/compatible/compliant environment
for ISV's as well.  A simple (rpm specific) packaging rule to achieve that
goal might be to hide all the flavors behind a single dependency:

	Provides: LSB

3) LSB establishes the deeper semantics that establish the connection
between the provides and requires, basically by defining appropriate
conformance tests.

So a "boundary package" is a (but not necessarily THE) solution, a
package that does all of
	a) encapsulates software, reports, standards doco, etc that
	describes the methodology.
	b) builds the test software.
	c) runs the tests.
	d) generates test reports.
	e) (not yet) if tests pass, then generates the dependency
		Provides: LSB

You can find an example of such a "boundary package" at

	ftp://people.redhat.com/jbj/lsb-redhat-0.9-1.src.rpm

probably also at

	http://people.redhat.com/~jbj/lsb-redhat-0.9-1.src.rpm

Now for the usual caveats and disclaimers:

	I made this package, not LSB, so blame me, not LSB or Red Hat
	or anyone else, for any and all problems associated with the
	software. I dunno what LSB is gonna do, dunno what Red Hat is
	gonna do, dunno what rpm is gonna do, this package is purely
	an experiment produced to elicit specific comments about a
	possible solution.

Specifically, this is a very shoddy packaging job (by me) of some standards
conformance tests to illustrate a possible approach to LSB standardization
through a "boundary package" concept. In particular, note carefully that
users/groups necessary to run the (proposed) conformance tests will be added
and deleted during the package build. If that's not to your taste, then
don't build the package. Otherwise, examine the spec file, and build as root.
 
I'm interested in comments, particularly from DSV's, regarding a
"boundary package" approach to LSB standardization.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@jbj.org	(jbj@redhat.com)
Chapel Hill, NC

_______________________________________________
Rpm-list mailing list
Rpm-list@redhat.com
https://listman.redhat.com/mailman/listinfo/rpm-list

----- End forwarded message -----

Regards,
	Dmitry

+-------------------------------------------------------------------------+
Dmitry V. Levin     mailto://ldv@alt-linux.org
ALT Linux Team      http://www.altlinux.ru/
Fandra Project      http://www.fandra.org/
+-------------------------------------------------------------------------+
UNIX is user friendly. It's just very selective about who its friends are.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]