jheiss
commented
11 years ago Just to record my own internal debate, elsewhere I proposed an alternate implementation of having a separate "init" package that had this logic rather than embedding the logic in tpkg itself. A la logrotate, etc. However, tpkg currently has command-line options to start/stop/etc. init scripts. If we moved the init functionality to a separate package we'd have to strip those command-line options out and put a separate app in the init package, "tpkginit" or the like. Although I sort of like the idea of keeping tpkg itself lean and mean that would be a big, incompatible change that would require repackaging lots of apps. And init functionality seems like a near-universal need. So on further thought I think a separate init package is not the right approach.
Was: https://sourceforge.net/apps/trac/tpkg/ticket/13#comment:1
If a package has init scripts tpkg currently symlinks those into an appropriate OS directory so that they are started at system boot time. In order to increase portability, and to give us more control over the process, we should have tpkg insert its own init script into an appropriate system location and then start all package init scripts itself.
One item in particular that this would enable is for us to source /opt/tpkg/etc/profile.d/* before running init scripts, as it is a common feature request that users be able to set environment variables that are always available to their application.
Was: https://sourceforge.net/apps/trac/tpkg/ticket/13