Re: LSB Commands and Utilities, Draft proposal
I thought the primary concern for now was binary compatibility? This is the
biggest problem, IMO; that different distributions ship different versions
of system libraries (for example, libc5, glibc2.0, glibc2.1 all of which have
some incompatibilities with each other) and thus software vendors (especially
closed-source venders) have a hard time deciding how to build their programs
to reach the largest target audience. That's why you see vendors supporting
individual distributions, mostly Red Hat here in the states. That should
end, and the LSB should provide the mechanism for it.
If it were up to me (which it is NOT), I would divide the LSB into logical
categories of compliance...
Core Libraries - this category includes the base libraries needed to run
a majority of applications, including glibc and associated libraries, ld.so,
etc. This does not include development libraries (i.e. header files),
libraries for utilities (Perl modules, etc) or GUI libraries (such as Xlib).
In this case, it would include only the ELF-format shared libraries (and
static libraries, where appropriate) and their dependancies which are
considered a "core" requirement for the average app to run. Core libraries
may only depend on other packages in this category.
Filesystem - this category would contain the FHS (or whatever it's called
these days). Each other category would specify where in the filesystem
its stuff should go (for example, the filesystem category would leave
a /lib directory in the filesystem, but it would be up to the system libraries
category to specify that that's where glibc stuff goes (and possibly in
/usr/lib too). Non-standard packages would simply be expected to follow the
guidelines of the the FHS.
Extension Libraries - this category would include those libraries which are
common, but not mandatory, for applicatios use. Glib would be an example of
this. Windowing system libraries such as Xlib, GTK+, (eventually) Berlin
would be included here as well. Desktop environments (such as GNOME, KDE,
Moscow) would be included here until such time that a de-facto standard emerges
(GNOME and KDE become compatible enough for their functionality to be
codified, for example). Preferably, when a baseline of functionality for
desktop environments can be clearly distinguished and is in widely-accepted
usage, desktop environments would be a seperate category. Each extension
library package would be optional; the LSB would simply be defining the
standard way to use, version and locate these libraries. I suspect much of
this specification would come from the maintainers themselves and simply be
reviewed, checked for compliance with other LSB packages/categories (such as
the FHS), approved and included by the LSB staff. Extension libraries may
depend on other extension library packages, or core library packages.
Core utilities - applications such as bash, Perl, etc. which are not
libraries and not necessary for binary compatibility but nonetheless are
core components of most any system. This would also include common interpreters
in addition to Perl, common archiving software (such as tar, gzip, cpio),
commands (such as ls, rm, mv, cp, etc), etc. Basically those programs needed
to make the system usable by scripts, sysadmins and users alike. Core
utilities may depend on other core utilities or core libraries.
Administration utilities - this includes those utilities and their
dependancies not already included in the Core utilities and Core libraries
categories whose primary purpose is administration (that is, most of the
things found in /sbin and /usr/sbin). For instance, traceroute, ipchains,
pppd, shutdown, etc. This would also include a standard packaging system.
My opinions/ideas on that are found below. Administration utilities may
depend on other administration utilities, core utilities or core libraries.
Extension utilities - other utilities commonly found in /bin, /usr/bin,
/sbin, and /usr/sbin (and anywhere else utilities are found in per the
FHS) which are not covered by the Core or Administration categories but are
common across distributions and in high usage. Like extension libraries, each
of these packages would be individually optional. An example would be Apache
(I think). Extension utilities may depend on other extension utilities,
core utilities, extension libraries or core libraries.
Development libraries - not actually a seperate category, each of the
above categories would have a development sub-category which would define
the package(s) needed to develop applications which depend on a package in
the the category. For example, the glibc-devel package would be in the
development sub-category of the core libraries category because it includes
the necessary files for developing programs which utilize glibc.
These categories contents thus defined, I would then define levels of
compliance within the LSB, which third-party applications could then
visually require (in a Requirments sticker on the box, for example):
Level 0 (Base): any distribution which is LSB-compliant must
contain the packages defined in the Filesystem and Core Libraries categories,
not including any Development packages of those categories.
Level 1 (System): distributions which are Level 1 compliant must
also be Level 0 compliant. Level 1-compliant distributions would include
all the packages in the Core utilities category, not including any
Development packages of those categories.
Level 2 (Administration): distributions which are Level 2 compliant must also
be Level 1 compliant. Level 2-compliant distributions include all packages
in the Administration utilities category, not including any Development
packages of those categories.
Compliance qualifiers - these qualifiers further distinguish compliance within
a specific level of complance:
Extended - A distribution which contains Extened compliance includes one or
more packages which are a part of the Extension libraries or Extension
utilities categories. An application which requires a specific package included
in one of those categories must also be qualified as requiring Extended
functionality. Within such software's user-documentation, the specific package
requirements must be documented, so that the user may install any necessary
packages needed to meet the software's requirements.
Development - A distribution which contains Development compliance must
include all development packages of any of the categories included in the
distribution. For example, a Level 1-compliant distribution must include
all development packages defined in the Core utilities and Core libraries
categories. Of course, actual installation of the development packages are
optional. This qualifier does not deal with development packages defined in
the Extension categories; that is considered beyond the scope of the LSB.
* An LSB package is one recognized by the LSB and containing, at a minimum,
the files, features and functionality defined by LSB in the corresponding
category. An LSB package must be recognized by the LSB as being compliant
(for instance, if the util-linux package is a part of the LSB, then
an RPM of util-linux must be certified to be considered LSB-compliant, as
would a Debian package of util-linux). Derivative packages containing source-
level modifications would require seperate certification.
And lo, the chronicles report that Daniel Quinlan spake thusly unto the masses:
>
> "Jakob 'sparky' Kaivo" <jkaivo@ndn.net> writes:
>
> > 1) There may be more commands that should be specified (e.g. the
> > package manager, /sbin/shutdown).
>
> There needs to be, at the very least, a way to install/upgrade/remove
> LSB packages. I would leave the command syntax unspecified, but leave
> a place for it.
My idea here is that the LSB define a library (call it what you want,
libpackage, for instance) which provides all the functionality of a package
manager for which standardization is deemed beneficial, but which actually
provides a wrapper for a distribution-defined package manager. For example,
on my Red Hat system, libpackage would interface with librpm. Then, the
LSB could create a utility which provides the functionality of the library
on the command line. These would be included that in the Administration
utilities category (this may require an exception to the rules in that the
standard package manager library would depend on a non-standard package).
Then, applications requiring the functionality of a package manager could
do so programmatically in a standard way, as could scripts requiring the
same, and simply system administration could be done in a standard way.
If the LSB defines a standard package format, which I think is a good idea,
then libpackage should be able to translate, if necessary, standard packages
to the underlying package format. For instance, if the standard package format
is the RPM format, then I should still be able to install packages in the
standard format on a Debian system (transparently using dpkg or whatever)
without having to perform any extra operations (for instance, manually
converting the package using alien- alien should be used underneath the hood
when installing the package via libpackage). This being the case, the
standard package format should be chosen based on technical merit (if the
format used in Debian packages is better, then that is used), since it
will be compatible with libpackage on any distribution regardless of
popularity, or the LSB should define a new format, perhaps based on its
ability to easily be converted to the more popular formats (RPM, Debian,
cpio, etc).
Similarly, libpackage would then require functionality to create new
packages in the standard format from distribution-specific formats.
> > Printing commands - cancel, lp, lpstat, pr
> > Divergence: These commands are not required by LSB. Instead, the BSD printing
> > commands (lpq, lpr, lprm, lptest, lpc, lpd, lpf, and pac).
> > Rationale: These commands are from the System V style of managing printers.
> > Linux-based operating systems tend to use the BSD family of printing tools.
>
> Would it be accurate to say that applications only need to know how to use
> lpr and perhaps lpqm and lprm?
>
> Wrapping lpr to provide lp is not too difficult, but lpr is definitely the
> Linux de-facto standard printing command.
What would be nicer is a library containing the functionality of lp, lprm
and lpq. Then programs can manage print jobs much better than they do now
(i.e. escaping to a shell and executing the command and then parsing the
output). I doubt this should be done by the LSB or included in the LSB
until such a library exists and is in general usage, but it would be a nice
little thing to have.
--
Aaron Gaudio
icy_manipulator @ mindless.com
http://www.rit.edu/~adg1653
--------------
"The fool finds ignorance all around him. The wise man finds ignorance within."
--------------
Use of any of my email addresses is subject to the terms found at
http://www.rit.edu/~adg1653/email.shtml. By using any of my addresses, you
agree to be bound by the terms therein.
Reply to: