From The Linux Foundation

[edit] Comments on this Page

Add comments here.

[edit] General

(Some of the comments have been superseded by the consensus/under duscussion of LsbinstallProblems)

[edit] Failure behaviour -- Adding a file/item which already exists

• init.d/profile.d using package install: Is handled by the package manager - it refuses to install
• init.d/profile.d using lsbinstall: One proposal to use --package=<packagename> and some renaming scheme: But what is <packagename> to prevent naming collisions? And what happens (e.g. update) if the same package tries to install the same file?
• services: add the other items as alias? Fail?
• fonts: In principle, see above. How to change the name put into the fonts.* if one installs for the 5th time the same font? Or simply fail with exit status code FONT_EXISTS?

[edit] Enabling-/Disabling

To be used daemons are usually automatically started either at boot (init.d) or upon connection to a certain port ([x]inet), but sometimes an administrator installs a damon only to look the config and to deploy later. Usually it is a good idea not to enable these daemons at install time (e.g. get a security update & configure first), but some ISV prefer to enable them right a way. Currently, install_initd/remove_initd allows the ISV to decide to enable the init.d script - or not. In any case the admin only needs to dis-/enable the script without needing to copy any file.

It should therefore be possible to install inet and init files without enabling them. Having the ability to enable them might be useful too.

[edit] init

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

I actually see no pro or con to lsbinstall vs /etc/init.d/. Upon activating the scripts, it may handle it differently, but it should matter were it is installed before. If I remember a FreeBSD install correctly, there was a long boot script and as compatibility a /etc/rc.d/ directory though no standard FreeBSD script used that.

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

Post scriptum:

• Is was proposed for FHS 2.3 and will maybe part of 2.4 - or not since FreeBSD handles this differently; see http://bugs.freestandards.org/show_bug.cgi?id=37
• It is required for distributions complient to LSB 1.x and 2.x

[edit] profile

If one allows for direct installation (e.g. via package manager), then one needs to apply the naming conventions of init.d/cron.* scripts.

[edit] service

The first operand shall have the format %d/%s with the port number and protocol values (e.g. 22/tcp)

Shouldn't one require that the protocol is either tcp or udp? no - other protocols may be permitted on some systems. The protocol must be one supported by the implementation. However, we do not specify `/etc/protocols` (except FHS does??) so there is no good way to determine if the protocol is supported or not.

[edit] crontab

This installs a crontab (to typically /etc/cron.d/), the functionality to put a script (not a crontab) to /etc/cron.{daily,monthly,weekly,hourly}/ is different.

[edit] man

If it only adds the path to MANPATH there is not really a naming collision, if it insteads copies the file to /usr/share/man/*/ then there is the collision problem. Renaming a file causes a problem too - unless you use 'man -k', you won't find the file using 'man <bin>'.

• Section number needed to pass to lsbinstall?

[edit] Consensus comments

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

This does not allow for domains - should it?

[edit] 'Under Discussion' comments

• enable/disable things. This applies particularly to --type=init

I think inet is similarily affected

• If there is a enable function, then there should also be a check. This allows update scripts to keep the previous state (enabled/disabled)