From The Linux Foundation

The Future of the lsbinstall Command

To aid in the development of portable software packages, the LSB proposed the addition of a new command `lsbinstall` which provid post-install script support services. The command did not 'make the cut' for LSB 3.0, but was included as part of an informative annex to indicate future directions.

Bug 782 is the original reference (rollup) bug
Bug 962 tracks E&Os for the current spec draft
lsbinstall spec is the current spec, as it appears in Appendix B. Future Directions (Informative) of LSB 3.0.

The lsbinstall command is intended to solve the following problems:

where an install location is not in the LSB/FHS, to 'hide' it from the package and allow the distro the ability to install it in the right place for that distro
where the location is specified, to assist in managing the namespace in those locations (i.e. avoid collisions with other packages)
where the location is a shared file, to provide a mechanism for editing it. Example: the `/etc/services` file

Previous versions of the LSB have attempted to address these issues in different ways. In the case of init scripts, a tool is provided for installation, and namespace management rules are provided to avoide clashes. Somewhat accidentally, the install location for these files (`/etc/init.d`) was also added to the spec. In the case of crontab entries, the locations are specified and namespace rules again required. There is no mechanism for editing system repositories. There is no mechanism for handling an install where there are two or more common mechanisms (e.g. `/etc/inetd.conf` vs. individual files in `/etc/xinetd.d`). The namespace rules follow a three-level naming scheme which includes LANANA-registered names, a DNS based name, and names reserved to the distribution. This is complex because existing non-LSB (including distro-provided) installs are not required to follow the LSB conventions: the spec thus carves out somewhat cumbersome names for LSB-conforming packages to avoid conflicts.

The overall purpose of lsbinstall is to allow packages to be installed without requiring further manual administator setup action. The old model of a trained administrator for each system on which software is installed is rapidly breaking down with Linux desktops, server farms, grids, and other uses. Currently there are a number of things packages cannot do automatically, such as arrange for the newly installed binary to be in the user's search path, add entries to files and directories not specified in the LSB/FHS, etc.

Note that the sense of recent LSB discussions on this topic is that the more things can actually be moved into the spec as required and not be left to `lsbinstall` the better - use it as a last resort but not as a holding area for everything we think of that might become an issue.

The `lsbinstall` spec currently requires support for installation/check/removal of the following object types:

font

install a font file into the systemwide font repository, if the system supports one. There shall be one operand, that names a font file. Now withdrawn -- move to graphics in the future

Issues

Fonts are optional (because graphics is optional) only in the ISO sense. It is required in the LSB certification sense.

We need to specify what format of fonts may be accepated (including pointers to the definition of the formats). Probably use the file suffix to specify the type. .pcf & .ttf formats should be supported.

init

install an init script into the system specific location. There shall be one operand, that names an init script file. On success, a name suitable for use with the install_initd and remove_initd commands shall be printed to the standard output. See also Installation and Removal of Init Scripts.

The single operand shall be placed into a system specific location and configured to be active when a system boots into multi-user mode. The script will not be invoked as part of this installation.

Issues

Highly contentious at this stage.

Making this a 2 step process is even more invention.
Should this just be a wrapper for install_initd?
Even if it is more than a wrapper, should it invoke/replace install_initd?
The directory `/etc/init.d` was previously specified by the LSB; 3.0 has removed this implementation specification in favor of `lsbinstall`. However, everyone has `/etc/init.d` at this point, so why bother?
Not all platforms for which the LSB is targeted have /etc/init.d. Only those which have chosen to follow LSB have it.
There's been a claim that there are implementations not based on the use of scripts at all, but one assumes those systems would still have to accept init "scripts" from third-party software.

Tobias Burnus comments (on not specifying init.d):

I think this is unfortunate. All newer systems I'm aware of have the
init scripts under /etc/init.d/, which is also defined in the File
Hierachy Standard. The filename poses no problem since we have a
namespace. All files installed using the package software can (a) easily
be removed and (b) the user can use rpm -qf /etc/init.d/<file> (or on
DEB-Systems: dpkg -S /etc/init.d/<file>) to find out to which package
that file actually belong.

What problem is this copying actually  trying to solve?

>Does lsbinstall have an option to remove the init script? Do we
>specify, that the package has to remove this file if it is deinstalled?

I want to add the question what happens if the file is modified by the
user, especially if one does an update? Package managers have techniques
in place for this case (.rpmsave and .rpmnew for RPM systems).

Note ... in spite of Tobias' claim above `/etc/init.d` is not specified by the FHS.

Even though we have a namespace for which can be used for `/etc/init.d`, we do not forbid the distributions from stepping on this namespace, therefor the potential for collisions still exists. By letting lsbinstall handle everything, it can implement a resolution policy as determined by the distribution.

profile

install a profile script into a system specific location. There shall be one operand, that names a profile shell script. The behavior is unspecified if this name does not have the suffix .sh. The sh utility shall read and execute commands from all such profile shell scripts when invoked as an interactive login shell, or if the -l (the letter ell) is specified (see Shell Invocation).

Issues

The one documented requirement for lsbinstall! bug 830
Could also be simply solved by specifying `/etc/profile.d` as a location to install such files.
Not all implementations have a profile.d directory.
Another possible approach is to specify a location packages are allowed to install into (/etc/opt/something), and mandate that implementations look here for profile script actions.

service

ensure a service name and number pair is known to the system service database. When installing, there must be at least two operands. The first operand shall have the format %d/%s with the port number and protocol values (e.g. 22/tcp), and the second operand shall be the name of the service. Any subsequent operands provide aliases for this service. If any of the -r, --remove, -c or --check options are specified, there shall be a single operand identifiying the port and protocol values (with the same format as above).

Issues

An important and fairly easy to add feature

inet

add an entry to the system's network super daemon configuration. If none of the -r, --remove, -c or --check options are specified, the first operand shall have the format:

"%s:%s:%s:%s:%s:%s"

Otherwise, the first operand shall have the format

"%s:%s"

The fields in the first operand have the following meaning, in order:

svc_name - The name of this service. If the name does not contain a /, this should match the name of an already installed service (see also `getservbyname()`). If the name contains a / character, the behavior is unspecified.

Rationale: This version of the LSB does not specify `getrpcbyname()` nor the existence or format of the `/etc/rpc` file. Therefore, installation of RPC based services is not specified at this point. A future version of this specification may require names containing a / character to be Remote Procedure Call based services.

protocol

The name of a protocol. The name shall be one of those listed in `/etc/protocols`. If this attribute is not specified, the system shall use an implementation defined default protocol.

socket_type

One of the following values:

`stream` - the service will use a stream type socket. `dgram` - the service will use a datagram type socket. `seqpacket` - the service will use a sequenced packet type socket.

wait

If the value of this attribute is yes, once the service is started, no further requests for that service will be handled until the service exits. If the value is no, the network super daemon shall continue to handle further requests for the given service while that service is running.

Note: If the service has the socket_type attribute set to dgram, the wait attribute should be set to yes, since such services do not have any distinction between the socket used for listening and that used for accepting.

user

The name of a user from the user login database. The service started to handle this request shall run with the privileges of the specified user.

server

The name of a program to run to handle the request.

server_args

The arguments to pass to the program.

Alternately, this could be specified in either the simpler traditional inetd format, or as a colon seperated 6-tuple which is passed in as the argument. The latter has the advantage of not requiring an additional to be installed as part of the package.

-t inet "netbios-ssn:stream:tcp:nowait:root:/usr/sbin/smbd

crontab

Install a crontab into the system specific location. There shall be one operand, that names a crontab file. See Cron Jobs.

Issues

The Cron Jobs reference already specifies `/etc/cron.{daily,weekly,monthly}` and `/etc/cron.d` ... why do we need this?

package

Invoke the system specific package installation utility (or package removal utility if the -r or --remove option was specified). There shall be one operand, that names a package file.

Issues

See bug 874 for the problems with this

This one should just be removed. Removed

ldconfig

Register a directory that contains shared libraries with the system. There shall be one operand, that names a directory.

Note: If the -r or --remove option is specified, the named path will be removed from the system configuration, even if other packages depend on it. Shared library entries should only be removed from the system configuration when the calling application can guarantee no other package or utility depends on this library path,

Issues

Do we have adequate collision avoidance rules in place for this? What happens if I install my own private copy of libX11.so.6? How will it interact with the system provided library?

Maybe we shouldn't specify this, and rely on applications to link them selve such that they will find the version of the library they are looking for. out

man

Install a manual page into the appropriate system manual repository. There shall be one operand, which is the full path to a man page which is installed as part of the application. lsbinstall shall take whatever actions are needed to ensure that this page will be found by man.

Issues

Is this needed? Is it just for the purposes of `mkwhatis`? The profile can update `MANPATH`. bug 858 documents this.

So where does MANPATH get defined?

This is not just for mkwhatis.

As mentioned above for init scripts, the potential for collision with system provided pages still exists. Just using the profile mechnism is not sufficient. lsbinstall needs to own enough of the installation process so that it can perform for collision resolution process if needed.

Sample Implementation

This command is pure invention from the LSB team ... something we would not normally consider. However, it is felt that there is a big gap here that this command fills. But we need a sample implementation to flesh out the issues. One is in progress.

Perl Sample Implementation

Some quick design notes on the perl version now in cvs at `[lsb]/si/lsbinstall/perl`:

this is intended to be highly modular and highly configurable
specify a config file by the extension `-f file`
defaults to /etc/lsbinstall.conf
uses the CPAN module `Config::IniFiles`
generic functions go in the top level `lsbinstall.pm`
should be exported via `@EXPORT` or `@EXPORT_OK`
there needs to be a module for each type of thing lsbinstall can install
e.g. `lsbinstall::profile` or `lsbinstall::init`
modules must export four subs:
`new` to create a new installer
`install` to install a file
`check` to validate if a file is installed
`remove` to remove a file
modules return `true` or `false` from each of the main subs
generic function `err` sets an error string in a global place for later decoding, e.g.

return (err("$target: no such file"));

the `install`, `check` and `remove` subs all get passed a pointer to a `Config::IniFile` object as arg1.
use `$cfg->val("myobect","myvariable")` to access the value of `myvariable` in the inifile.
also passed are the unprocessed elements of `@ARGV` ... the operands to process.
Use lsbinstall::profile as a model
TODO
all the other types apart from profile!
profile check and remove do not deal with the `action=append` possibility
documentation -- POD style throughout
a Makefile.PL installer
tests

The Way Forward

For the teleconference, 2005-06-01.

At least two choices:

Move `lsbinstall` from the nomrative text to an informative annex, "Future Directions". The utility is still under development, the spec is nowhere near complete. Continue to develop the sample implementation. If this utility works, people will want it. Distros are under clear notice that they must make it work before the next release. Make the normative text include extensions to the FHS on where to install files, and enforce the namespace rules harder (a chksysconfig test).

better enforcement of the namespace rules - perhaps only allow apps to use the dns based namespace
extend FHS to include the dirs in /etc

#2 Stick the course ... delay LSB 3.0 for at least 4 weeks. Get the sample finished, the spec finished, tests written, etc. During this, be prepapred to reduce the functionality of `lsbinstall` to fit the timescale we have available.

profile, services, inetd all almost complete
better namespace management required -- needs a database
init, man are possible but not yet started

Test Case Development

V1.1 of the ASSERT and STRATEGY caputre exercise is complete and located in the cvs at <CVSROOT>`/tests/lsb-runtime-test/wip/lsbinstall/tset/ASSERTs`

This file can also be viewed at lsbinstall

See LsbinstallTest for more information on the lsbinstall test development.

Reviews are needed by end of Jun 3, 2005.

Summary of Consensus

This list represents high level desisions made since May 31 regarding lsbinstall Please correct as needed.

Name space contention will be (mostly) resolved with the --package option.

service does not need --package

2. lsbinstall -t man, init inet profile and service will be supported

man and init are still a bit under consideration

3. lsbinstall will not un-install service.

4. The spec needs to describe how lsbinstall will install files when collisions do occur.

5. All distro dependent factors will be captured in distro-specific config files. Does the spec need to describe the config file?

6. use of $0 to determine functionality is prohibited as names may be changed, though it is still OK to say, for example

echo "Usage: $0 options args" 2>&1"

7. hierarchical names based on LANANA and DNS will be used when re-naming (installing?) packages. This may lead to a registered name being installed to an unregistered name since some other non-conforming package had already pre-empted the name.

8. Fonts and menus are moved to Desktop

9. package names are [a-z][a-z0-9]* plus '-'

10. lsbinstall will not fail installing a service/proto that already exists. It won't do anything either (possible mutter something if --verbose is specified). Actually several possible options here: if there is already a service with this name at this port and this proto, then silently exit and do nothing else. If this name exists but a different port (same proto) ... possibly error. If this port/proto combination exists, but not this name, then add this name as an alias. If this name exists, but for a different protocol, then add the new line.

11. lsbinstall --remove will remove (or disable) the thing it installed, even if that thing was renamed during installation. Except for service.

12. crontab entries will not be installed with lsbinstall

13. lsbinstall should it move to an informative annex "Future Directions", and the directory locations and namespace rules should be strengthened in the interim.

Still Under Discussion - no real concensus

The following areas have generated some (sometimetimes lots) of discussion, but no concensus has yet formed:

Should lsbinstall also enable/disable things. This applies particularly to `--type=init`, where if it does also enable/disable, the `install_initd` or `remove_initd` functionality is also included.

2. Related to 1, on removal, is it necessary to disable (and possibly stop apps using it) the object before removal? So, if you remove an inetd service, do you also restart inetd? And do you hunt down and kill any app running whose name matches the app name being removed?

3. Should there be --enable and --disable options to explictly enable/disable things during installation?

[[[LsbinstallProblems]]/Comments User comments] [[Include(LsbinstallProblems/Comments)]]

[Article] [Discussion] [View source] [History]

From The Linux Foundation

Contents

The Future of the lsbinstall Command

font

Issues

init

Issues

profile

Issues

service

Issues

inet

crontab

Issues

package

Issues

menu

Issues

ldconfig

Issues

man

Issues

Sample Implementation

Perl Sample Implementation

The Way Forward

Test Case Development

Summary of Consensus

Still Under Discussion - no real concensus

Who are we?

Explore

Stay Current

About