Commit 36f28dd3 authored by Jaromil's avatar Jaromil

Import from Debian jessie/main package lsb-4.1+Debian13+nmu1

parents
lsb for Debian
--------------
This package provides the Linux Standard Base on Debian systems. The
LSB is a specification for allowing the same binary package to be used
on multiple distributions.
INSTALLING LSB PACKAGES
The "alien" package supports LSB packages on Debian. For example, to
install an LSB package "lsb-mozilla-1.2-1_i386.rpm", type (as root):
alien -i lsb-mozilla-1.2-1_i386.rpm
Ideally, the package should be converted to a Debian package and then
installed by dpkg. If this fails, there may be a problem with either
the lsb package (most likely) or alien (less likely), and you should
contact the vendor of the lsb package to resolve the problem.
PACKAGE LAYOUT
The LSB implementation in Debian is currently divided into eight
packages:
* The "lsb-core" package depends on the Debian packages that are
required to comply with the LSB-Core 4.1 specification. It also
includes some subroutines that are used by LSB-compliant applications
when they are being installed or removed.
* The "lsb-graphics" package depends on the X11 libraries required for
the LSB-Graphics 4.1 specification.
* The "lsb-cxx" package depends on libstdc++6, required for the
LSB-CXX (LSB-C++) 4.1 specification.
* The "lsb-desktop" package depends on the Gtk+ and Qt libraries required
for the LSB-Desktop 4.1 specification.
* The "lsb-languages" package depends on Python 2.4 and Perl 5.8.8 or later.
* The "lsb-multimedia" package depends on libasound2.
* The "lsb-printing" package depends on the CUPS libraries (libcups2
and libcupsimage2), foomatic-filters, and Ghostscript.
* The "lsb" package depends on all of the above packages.
* The "lsb-base" package includes a number of functions used by init.d
scripts in some LSB packages.
For documentation of those functions (and those added for Debian's use),
please see the README.Debian file in that package.
* The "lsb-release" package includes the lsb_release command, which provides
information about the installed LSB modules and the underlying distribution.
The LSB module packages are architecture-specific because of
differences in the requirements of the LSB on various binary
architectures. In particular, each package provides
lsb-{module}-noarch and lsb-{module}-{arch} virtual packages.
IMPLEMENTATION ISSUES
This package attempts to implement the core LSB specification. Much
of the implementation is drawn on a talk by Wichert Akkerman
(http://www.liacs.nl/~wichert/talks/LSBDistro/html/) and Matt
Taggart's discussion of LSB 1.0 and Debian. Matt has also produced a
slideshow on LSB in Debian, which can be found at:
http://people.debian.org/~taggart/debconf2/
This package implements the LSB specification by:
- depending upon packages that implement OS services required by the
LSB, including libraries and programs.
- including the correct symlink to the dynamic linker.
- providing the LSB init script functionality. Some of the LSB init
functionality cannot be implemented without cooperation from other
packages or changes in policy for sarge+1; however, the remainder is
provided here.
The intent of this package is to provide a best current practice way
of installing LSB packages on Debian using the Intel and PowerPC
32-bit architectures with the Linux kernel ("ia32" and "ppc32"). Its
presence does not imply that I or the Debian project believe that
Debian fully complies with the Linux Standard Base, and should not be
construed as a statement that Debian is LSB-compliant.
The specification is available at http://www.linuxbase.org/spec/
DEVIATIONS FROM LSB
The package and its dependencies implement all of LSB on Debian, with
these exceptions:
- LSB 3.2 doesn't fully specify what the init_functions should do. I
have chosen to implement them in a way that is consistent with
Debian current practice, using the start-stop-daemon utility and the
echo command. For sarge+1, I expect a nicer init logging facility
that could be used.
- LSB specifies no way for a binary to request that a pid file be
created for it, and the spec is ambiguous about whether start_daemon
should create the pid file, therefore I assume the binary will
produce its own /var/run/basename.pid file.
- Debian only implements certain features of adduser if shadow
passwords are enabled. The lsb package will prompt the user to
enable shadow passwords if they appear to be disabled; however, it
does not force this choice on the administrator. Administrators who
disable shadow passwords may find that some LSB applications fail to
operate correctly as a result.
(We do not consider this a bug in the package.)
- The LSB specifies that several X libraries must be available on the
system, but does not specify the presence of either an X server or
any X clients. However, many LSB packages may expect these things
to be present, despite their absence from the spec.
Similarly, the printing specification requires the CUPS libraries
but no CUPS binaries; hence, printing may be impossible unless you
actually install the cupsys package.
(This may be a deficiency in the spec. However, we comply as-written.)
- The LSB specifies that cron scripts can be placed in cron.daily and
other directories; however, Debian's run-parts appears to ignore
these scripts if they contain a dot in their names. (See #118646)
You can work around this problem by editing /etc/crontab and
specifying the --lsbsysinit option; it is hoped that eventually
Debian will include this option by default.
(This is a known deficiency in debianutils, and is required for
backwards compatibility with expected behavior on earlier systems.)
- /etc/profile.d scripts aren't executed on shell startup by default
on Debian systems (see Debian Policy section 9.9 for an explanation).
LSB 3.2 is ambiguous on this requirement; /bin/sh is *not* required
to execute these scripts, according to its description, but the
lsbinstall documentation says that it is.
Debian policy forbids the use of /etc/profile.d by Debian packages,
so it is unlikely this will change (as it might be seen as
encouragement for Debian developers to do use it.)
There may be other deviations from the spec; they are bugs in this
package and should be reported as such using Debian's bug tracking
system: see reportbug(1) or your favorite bug reporting tool. (The
aforementioned deviations are generally bugs in the package that
cannot be easily fixed, or are bugs in the specification itself that
we hope to resolve in the near future.)
For more discussion of these deviations, see:
http://lists.debian.org/lsb-spec/2001/lsb-spec-200107/msg00002.html
(a discussion of deficiencies in LSB 1.0, mostly resolved)
DESIGN DECISIONS
- I implemented the LSB init dependencies based on Debian policy's
update-rc.d support. A registry of package-provided facilities and
their start and stop priorities is retained in
/var/lib/lsb/facilities. Priorities are assigned to the system
facilities as found on my sid systems as of today; perhaps system
facilities should be registered by the appropriate packages, and not
managed by the lsb package, but that is a sarge+1 policy decision.
- As of 1.3-1, a second registry of init script dependencies is
retained in /var/lib/lsb/depends. This is used to ensure that an
LSB package will not be removed if it provides an LSB facility that is
used by another LSB package. (If you rely on this functionality and
are upgrading from the 1.2 series, you will need to manually reinstall
all of your LSB packages.)
- As of 3.0-2, a third registry of files installed by lsbinstall is
retained in /var/lib/lsb/lsbinstall. Unlike the other two registries,
it is not designed to be human-readable.
- The facility handling scripts are written in Python. I am not
particularly attached to them being written in Python, but at the
same time I do not forsee rewriting them in $language_of_choice.
COMPLIANCE TESTING
I have been unable to locate any LSB package that tests the init
script functionality of the spec. I am therefore unable to say
whether this package actually works as advertised. I would appreciate
any reports of its success or failure.
An example init script that tests some of these features is provided
as /usr/share/doc/lsb/examples/init-skeleton.
-- Chris Lawrence <lawrencc@debian.org>, Sun, 2 Mar 2008 02:20:47 -0600
LocalWords: LSB
A quickie TODO list for lsb*:
* Finish lsbinstall
* Move dynamic linker symlinks from postinst into package itself. (?)
* Only build lsb-* for LSB architectures in Debian.
* Make lsb stuff available in a Python package.
This diff is collapsed.
This diff is collapsed.
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: LSB implementation package
Files: *
Copyright: 2002-2010, Chris Lawrence <lawrencc@debian.org>
License: GPL-2
Files: init-functions.d/50-ubuntu-logging
Copyright: 2005-2011, Canonical Ltd.
License: GPL-2
Files: init-functions
Copyright: 2002-2009, Chris Lawrence <lawrencc@debian.org>
License: BSD-3-clause
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. Neither the name of the author nor the names of other contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS''
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS
BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE
OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
License: GPL-2
This program is free software; you can redistribute it
and/or modify it under the terms of the GNU General Public
License as published by the Free Software Foundation;
version 2 dated June 1991.
.
This program is distributed in the hope that it will be
useful, but WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE. See the GNU General Public License for more
details.
.
You should have received a copy of the GNU General Public
License along with this package; if not, write to the Free
Software Foundation, Inc., 51 Franklin St, Fifth Floor,
Boston, MA 02110-1301 USA
.
On Debian systems, the full text of the GNU General Public
License version 2 can be found in the file
`/usr/share/common-licenses/GPL-2'.
lsb (4.1+Debian1) unstable; urgency=low
This version implements a new "Fancy output" in the form of "[....] "
blocks prepended to the daemon status messages:
Before:
Starting/stopping long daemon name: daemond daemon2d
After:
[....] Starting/stopping long daemon name: daemond daemon2d
This block will become either a green [ ok ], a yellow [warn]
or a red [FAIL] depending on the daemon exit status.
The "Fancy output" can be disabled by setting the FANCYTTY variable to 0
in the /etc/lsb-base-logging.sh configuration file.
-- Didier Raboud <odyx@debian.org> Thu, 19 Apr 2012 11:25:01 +0200
lsb-base for Debian
-------------------
The Debian lsb-base package provides a series of logging functions to
permit simplified logging of init script actions. These functions are
specific to Debian and (in some cases) other derived distributions.
- log_daemon_msg "Starting/stopping long daemon name" "daemond"
Log starting/stopping of daemons. On Debian, outputs:
"Starting/stopping long daemon name: daemond"
and leaves the cursor at the end of the line. If "Fancy output" is
enabled, outputs:
"[....] Starting/stopping long daemon name: daemond"
and leaves the cursor at the end of the line.
- log_progress_msg "daemon2d"
Log startup of a second daemon (e.g. sysklogd, nfs init scripts).
On Debian, outputs " daemon2d" and leaves the cursor at the EOL.
- log_end_msg 0/1
Log successful startup. On Debian, outputs "." followed by newline.
A non-zero code may also be specified, which indicates failure;
currently implemented as outputting "failed!" (in red on a color
TTY) followed by newline.
Unsucessful startup will cause the specified failure code to be
returned by this function; unless trapped, this may end your init
script depending on whether or not set -e is used.
If "Fancy output" is enabled, it will store the cursor position,
move it to the start of the line, write a colored "[ ok ]", "[FAIL]"
or "[warn]" and restore the cursor position. This has the effect of
updating the "[....]" printed by log_daemon_msg.
- log_action_msg "Setting VARIABLE to VALUE"
Log an atomic action by your init script. Typically, this is the
setting of a kernel variable, but it might be something else that is
not expected to take any time (or fail).
On Debian, a trailing period will be added to the message, followed by
a newline. If "Fancy output" is enabled, the message will get prepended
with a blue [info].
- log_action_begin_msg "Configuring network interfaces"
Log the start of an action that is expected to take some time. On
Debian, an elipsis (...) will follow the message, and the cursor will
stay at EOL.
If "Fancy output" is enabled, it will get the same [....] block as
log_daemon_msg.
- log_action_cont_msg "flushing ARP cache"
Log an action as part of a process started by log_action_start_msg().
On Debian, this message will receive a trailing elipsis, and the cursor
will stay at EOL.
- log_action_end_msg {0|1} ["message"]
Log the end of the action started by log_action_start_msg(). If one
argument is supplied, either "done." (0) or "failed." (1) will be output,
followed by a newline. If a second argument is supplied, the message
will appear as follows:
"done (your message here)." --- if first argument is 0
"failed (your message here)." --- if first argument is 1
This argument must be quoted, or otherwise only the first word will
be output.
On color TTYs, the failure messages will be red.
Note that unlike log_end_msg(), this function does not return the
first argument as its exit code.
- status_of_proc [-p pidfile] pathname "Daemon_name"
Log the status of a process and return an LSB-compliant exit status
code:
0 program is running or service is OK
1 program is dead and /var/run pid file exists
2 program is dead and /var/lock lock file exists
3 program is not running
4 program or service status is unknown
5-99 reserved for future LSB use
100-149 reserved for distribution use
150-199 reserved for application use
200-254 reserved
On Debian, outputs:
"Daemon_name is running.".
"Daemon_name is not running ... failed!"
The pidfile path will be used as argument for pidofproc and must be
provided if the pidfile is not /var/run/$daemon_basename.pid.
status_of_proc can be used to easily implement the "status" argument
of init scripts:
status)
status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
;;
- init_is_upstart
If the currently running init daemon is upstart, return zero; if the
calling init script belongs to a package which also provides a native
upstart job, it should generally exit non-zero in this case.
init_is_upstart is available since lsb-base 4.1+Debian3.
To use these functions, source /lib/lsb/init-functions at the
beginning of your (Bourne sh or compatible) init script.
Please depend on lsb-base to ensure all of these functions are available
for your init scripts.
LSB LOGGING FUNCTIONS
This package also includes the LSB-specified logging functions:
log_success_msg message
log_failure_msg message
log_warning_msg message
These functions *do not* comply with Debian policy and should only be used
by LSB packages.
OTHER LSB FUNCTIONALITY
start_daemon [-f] [-n nicelevel] [-p pidfile] pathname [args...]
Start "pathname" as a daemon. We call Debian's start-stop-daemon to
implement this functionality.
killproc [-p pidfile] pathname [signal]
Stops "pathname" (using "pidfile", if specified, to find the process
ID). This is implemented using start-stop-daemon as well.
pidofproc [-p pidfile] pathname
Find the process ID of pathname. If the pidfile is specified, we use the
first space-delimited word; otherwise, /bin/pidof is used from the
sysvinit package, if available.
For full documentation, please refer to:
http://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html
Note: Debian packages probably should use start-stop-daemon directly;
however, these functions may be useful in porting init scripts from
other distributions. Also, if you are developing software for wider
use, you should not expect these functions to be implemented
identically on other LSB-conforming distributions; the only guaranteed
behaviors are those in the specification above.
CUSTOMIZING LOGGING OUTPUT
- FOR PACKAGES AND DISTRIBUTIONS
Since lsb-base 4.1+Debian4, init-functions will source all
correctly-named files under /lib/lsb/init-functions.d for the purpose of
allowing packages to alter or enhance the init-functions functions.
By providing a file in there, any package or derivative distribution can
override the default behaviour of /lib/lsb/init-functions: logging init
script events, changing the logging messages format, etc.
If supplied, these script fragments shall be compatible with any Debian
/bin/sh, as init scripts sourcing /lib/lsb/init-functions may be running
under any Bourne-style shell permitted by Debian policy (i.e. not just
bash).
- FOR ADMINISTRATORS
After those distribution-provided files, if it exists,
/etc/lsb-base-logging.sh will be sourced by /lib/lsb/init-functions.
This file is to be supplied by the administrator for machine-specific
overrides. This file may also be useful on systems where the console log
is not visible during startup.
If supplied, this script fragment should be compatible with any Debian
/bin/sh, as init scripts sourcing this file may be running under any
Bourne-style shell permitted by Debian policy (i.e. not just bash).
- FANCY OUTPUT
"Fancy output" can be overridden by setting FANCYTTY=0 in
/etc/lsb-base-logging.sh .
- OUTPUT FUNCTIONS
From lsb-base 3.2-14, you can use the following hook functions which
are called by the appropriate functions, instead of supplying your own
logging functions:
log_daemon_msg_pre
log_daemon_msg_post
log_begin_msg_pre (since 4.1+Debian1)
log_begin_msg_post (since 4.1+Debian1)
log_action_msg_pre (since 4.1+Debian1)
log_action_msg_post (since 4.1+Debian1)
log_action_begin_msg_pre (since 4.1+Debian1)
log_action_begin_msg_post (since 4.1+Debian1)
log_end_msg_pre
log_end_msg_post
log_action_end_msg_pre
log_action_end_msg_post
Each function receives all of the arguments sent to the parent
function; the "pre" functions operate before any output, while the
"post" functions operate after the output is produced.
FANCY OUTPUT, KNOWN BUGS
* Daemons writing too much information on the screen (hence getting
their output spawned on multiple lines) won't get their [....]
replaced by [ ok ] as the replacement will happen on the last input
line.
* The above has the side-effect of hiding 7 characters of potentially
useful output.
* init.d scripts not using the /lib/lsb/init-functions provided
functions will (obviously) not get the fancy output.
-- Chris Lawrence <lawrencc@debian.org>, Sat, 18 Sep 2010 17:09:57 -0500
-- Didier Raboud <odyx@debian.org> Mon, 21 May 2012 15:00:10 +0200
/lib/lsb/init-functions.d
init-functions /lib/lsb
init-functions.d/20-left-info-blocks /lib/lsb/init-functions.d
rm_conffile /etc/lsb-base-logging.sh 4.1+Debian4 lsb-base
#!/bin/sh
set -e
. /usr/share/debconf/confmodule
if [ ! -e /etc/shadow ]; then
db_input medium lsb/shadowconfig || true
fi
db_go
#DEBHELPER#
usr/lib/lsb
var/lib/lsb
etc/profile.d
test/init-skeleton
initdutils.py /usr/lib/lsb
install_initd /usr/lib/lsb
remove_initd /usr/lib/lsb
lsbinstall /usr/lib/lsb
# The purpose of LSB is to ensure that those packages are present. Being explicit cannot hurt.
depends-on-essential-package-without-using-version depends: bsdutils
#!/bin/sh
set -e
setup_ldso_symlink () {
ARCH=$DPKG_MAINTSCRIPT_ARCH
if [ -z "$ARCH" ]; then
ARCH=$(dpkg --print-architecture)
fi
case "$ARCH" in
s390|ppc64|sparc|sparc64|alpha|hppa|m68k|mipsel)
ln -sf ld.so.1 /lib/ld-lsb-$ARCH.so.1
ln -sf ld.so.1 /lib/ld-lsb-$ARCH.so.2
ln -sf ld.so.1 /lib/ld-lsb-$ARCH.so.3
;;
powerpc)
ln -sf ld.so.1 /lib/ld-lsb-ppc32.so.1
ln -sf ld.so.1 /lib/ld-lsb-ppc32.so.2
ln -sf ld.so.1 /lib/ld-lsb-ppc32.so.3
;;
i386)
ln -sf ld-linux.so.2 /lib/ld-lsb.so.1
ln -sf ld-linux.so.2 /lib/ld-lsb.so.2
ln -sf ld-linux.so.2 /lib/ld-lsb.so.3
;;
amd64)
ln -sf ld-linux.so.2 /lib/ld-lsb.so.1
ln -sf ld-linux.so.2 /lib/ld-lsb.so.2
ln -sf ld-linux.so.2 /lib/ld-lsb.so.3
ln -sf ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.2
ln -sf ld-linux-x86-64.so.2 /lib64/ld-lsb-x86-64.so.3
;;
ia64)
ln -sf ld-linux-ia64.so.2 /lib/ld-lsb-ia64.so.1
ln -sf ld-linux-ia64.so.2 /lib/ld-lsb-ia64.so.2
ln -sf ld-linux-ia64.so.2 /lib/ld-lsb-ia64.so.3
;;
*)
echo "ld-lsb-*.so.1 symlink for $ARCH is unknown!"
;;
esac
}
PATH=/sbin:/usr/sbin:$PATH
export PATH
. /usr/share/debconf/confmodule
case "$1" in
configure)
if [ ! -e /etc/shadow ]; then
db_get lsb/shadowconfig
if [ "$RET" = "true" ]; then
shadowconfig on >&2 || true
fi
fi
if dpkg --compare-versions "$2" lt "3.2+Debian30" ; then
[ -L /lib/ld-lsb-x86-64.so.2 ] && rm /lib/ld-lsb-x86-64.so.2 || true
[ -L /lib/ld-lsb-x86-64.so.3 ] && rm /lib/ld-lsb-x86-64.so.3 || true
fi
setup_ldso_symlink
;;
abort-upgrade|abort-remove|abort-deconfigure)
;;
*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
esac
#DEBHELPER#
#!/bin/sh
set -e
remove_ldso_symlink () {
ARCH=$DPKG_MAINTSCRIPT_ARCH
if [ -z "$ARCH" ]; then
ARCH=$(dpkg --print-architecture)
fi
case "$ARCH" in
s390|ia64|ppc64|sparc|sparc64|alpha|hppa|m68k|mipsel)
rm -f /lib/ld-lsb-$ARCH.so.[123]
;;
powerpc)
rm -f /lib/ld-lsb-ppc32.so.[123]
;;
i386)
rm -f /lib/ld-lsb.so.[123]
;;
amd64)
rm -f /lib/ld-lsb.so.[123] /lib64/ld-lsb-x86-64.so.[23]
;;
*)
echo "ld-lsb-*.so.1 symlink for $ARCH is unknown; not removed."
;;
esac
}
PATH=/sbin:/usr/sbin:$PATH
export PATH
case "$1" in
remove)
remove_ldso_symlink
rm -f /var/lib/lsb/facilities
rm -f /var/lib/lsb/depends
;;
failed-upgrade|upgrade|deconfigure)
;;
*)
echo "prerm called with unknown argument \`$1'" >&2
exit 1
;;
esac
#DEBHELPER#
# These templates have been reviewed by the debian-l10n-english
# team
#
# If modifications/additions/rewording are needed, please ask
# for an advice to debian-l10n-english@lists.debian.org
#
# Even minor modifications require translation updates and such
# changes should be coordinated with translators and reviewers.
Template: lsb/shadowconfig
Type: boolean
Default: true
_Description: Enable shadow passwords?
The Linux Standard Base requires that certain features of adduser(8)
be available to conforming applications (such as password
aging). These features are only provided when shadow passwords are
enabled, while this system has them disabled.
.
Most LSB applications will work fine with either setting, but complete
conformance requires shadow passwords to be enabled.
.
Generally speaking, it is considered good practice to enable shadow
passwords. However, there are some situations in which shadow passwords
may not work properly (most notably, if non-root users need to
check passwords against /etc/passwd).
# LSB packages are empty on purpose
empty-binary-package
lsb (4.1+Debian7) unstable; urgency=low
From its 4.1+Debian7 version on, lsb-desktop doesn't depend on Qt3 anymore.
This is an explicit and Debian-specific derogation from the LSB 4.1
specification.