Comments on LsbInstall follow.
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.)
/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.
/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:
/etc/init.d/boot) or bash (
/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:
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]).
/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
/usr/bin/installis not part of lsb-core) may at least provide the LSB Packager an option to simplify install/uninstall scripts.
/etc/xinetd.dbeing excluded from FHS 2.3 must be investigated and listed.