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/profilewill 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
*.shPOSIX 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
- 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 (
- 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/bindfor the ISC Bind server, once by the distribution and once by an ISC etc. But those will rather clash in
/etcand 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.
/etc/init.d/opt_bind_bindwill be installed. Now the user follows the manual and starts the server manually by
/etc/init.d/bindor 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>/packageis what FHS imposes, and if followed by all distros, will make a lot of issues concerning
/optsimpler and (
lsbinstallwill not be required to handle installation tasks related to
- 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/installis 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.dbeing excluded from FHS 2.3 must be investigated and listed.