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

Dmitry V. Levin =?iso-8859-1?q?ldv_=CE=C1_alt-linux=2Eorg?=
Пт Май 4 11:17:12 MSD 2001

----- 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

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


probably also at


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

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


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.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 232 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20010504/0aa376f3/attachment-0001.bin>

Подробная информация о списке рассылки Devel