Talk:LsbInstall

From The Linux Foundation

Comments on LsbInstall follow.

Some general comments

I (TobiasBurnus) think in general it is more robust to reduce the number of layers of scripts, to do it more like the distributions do and as ISV do tradionally, and handle more by the filesystem than by scripts. (KISS, keep it simple and stupid, is not the worst philosophy.)

The currently proposed script for adding a file(content) to
```
/etc/profile
```
will most likely just do a copy or move of the file to
```
/etc/profile.d
```
, with more or less checks for border cases and with different conflict resultion, which every distribution has to reimplement (each differently). How about simply adding
```
/etc/profile.d
```
and allow
```
*.sh
```
POSIX scripts to be installed there? It removes a whole bunch of problems, including some deinstallation problems as it is under package-manager control. The only problem left is the name-clash problem.

Name-clash problem: Due to fears of name-clashes, several simple solutions, such as
```
/etc/profile.d
```
(not in LSB [yet?]) and
```
/etc/init.d
```
(in LSB version 1.x to 3.x) but potentially also
```
/etc/cron.*/
```
(in LSB version 1.x to 3.x), are threatend to be complicated. Some notes:
There might by also
```
/opt/<package>/
```
clashes
LANANA is quite stable and using company-myproductname or even myproductname (even without LANANA registration) should be rather stable, unless I happen to have the product boot (
```
/etc/init.d/boot
```
) or bash (
```
/etc/profile.d/bash.sh
```
)
Most clashes I deem to happen are those: the same product by different providers, e.g. /opt/openoffice.org by OpenOffice.org vs. by the distributions; or
```
/etc/init.d/bind
```
for the ISC Bind server, once by the distribution and once by an ISC etc. But those will rather clash in
```
/opt
```
than in
```
/etc
```
and if they do, better deinstalling one than having a mess. Or if needed, do it manually (sys admin task: simply unpacking in different directories, rebuild package, recompile&package etc.) -- sometimes it is better to fail than o fix things behind the scene.

I think thus that lsbinstall is not needed in the most real-world cases as no clashes occure, in a large part of the others, it does not help. For the last class, it may make things even worse for the user: Imaging a Distribution and ISV installed Bind. Let them install as /usr/sbin/bind and in /opt/bind respectively and they don't clash. Now install the initscript "bind" via lsbinstall. As it already exists, something like e.g.

/etc/init.d/opt_bind_bind

will be installed. Now the user follows the manual and starts the server manually by

/etc/init.d/bind

or activate it himself (the user then types e.g.

chkconfig bind on

). The result is not what the user expects. In addition it makes the writing of handbooks very hard: Please start the server by running
/etc/init.d/server
, the filename can be different, consult your distribution's documentation. And if the daemon is automatically enabled (bad practice), you may end up running two daemons at the same time!

Therefore, I vote for:

init scripts: Keep status quo!
profile: Add profile.d and keep out of lsbinstall
/etc/services: Nice for a script. Thinking about removal: remove only services which installed by this package, a previous service line which was there before should not be removed. (Debian policies prohibits removal at all.)
(x)inetd: (a) File installation: nice to have as inetd & xinetd are both in use. b) (de)activation: very nice to have

Thanks for the comments.

I (SunilBeta) see a lot of rationale in those (particularly having /etc/profile.d as a standard - would need to ask the Debian maintainers on their opinion as they are the ones who don't keep one [correct me if I'm wrong]).

I see issues when LSB packages and non-LSB packages (Distro native or otherwise) want to co-exist.
```
/opt/<provider>/package
```
is what FHS imposes, and if followed by all distros, will make a lot of issues concerning
```
/opt
```
simpler and (
```
lsbinstall
```
will not be required to handle installation tasks related to
```
/opt
```
.
When a user builds a package and installs from sources, probably not following LSB norms, and that is followed by a "Distro Independent" LSB Package, I see the collision issues taking serious priority. (after all one should not remove freedom from the user?)
replacing the oft-used "install-sh" with a standard tool (when
```
/usr/bin/install
```
is not part of lsb-core) may at least provide the LSB Packager an option to simplify install/uninstall scripts.
The (x)inetd rationale is valid as many distros support both, perhaps reasons for
```
/etc/xinetd.d
```
being excluded from FHS 2.3 must be investigated and listed.

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