[This is and remains an annoyance to me.]
After some installs, an install message shows. Except it is a dependency
of a package to be installed later; then it flushes by and is gone. Some
packages have install messages, others don't.
It needs my eyes being glued to the screen or browsing
/var/db/pkg/foor/bar to see the message - *if* there is one.
Example:
-- php5-core-5.0.3p1 -------------------
To finish the install, enable the php5 module with:
/usr/local/sbin/phpxs -s
To enable parsing of PHP scripts, add the following to
/var/www/conf/httpd.conf:
AddType application/x-httpd-php .php
Copy the config file below into /var/www/conf/php.ini
/usr/local/share/examples/php5/php.ini-recommended
-----------------------------------------
I was bitten by this problem a few days ago (see post):
At an upgrade, what needs to be done again ?
[Please, no posts of RTFM; I could; but I am not paid to take all this
hassle; and find out what all of these do; where, and how often]
Suggestion:
Write the post-install message as scripts with comment lines.
Remember those packages only that generate a '+DISPLAY', at some place.
At any convenient moment, we can call up a small utility 'foo' showing these
script(s), in the sequence of the installs, one by one. At the same time
we'd be given a chance to execute the scripted part. Now comes the trick:
if we so did (execute); this would be remembered and this script executed
again at an update. Respectively not being executed at an update if we
declined the execution.
Therefore, the upper example could look like
#-- php5-core-5.0.3p1 -------------------
# To finish the install, enable the php5 module with:
/usr/local/sbin/phpxs -s
# To enable parsing of PHP scripts, add the following to
# /var/www/conf/httpd.conf:
# AddType application/x-httpd-php .php
# Copy the config file below into /var/www/conf/php.ini
# /usr/local/share/examples/php5/php.ini-recommended
#-----------------------------------------
Firstly, there would be a user-friendly way to activate newly installed
packages.
Secondly, it will still follow the philosophy of OpenBSD:
You "need to know" and act in order to get a service activated.
Thirdly, at an update specific action would be repeated; triggered by the
user having done it earlier.
Of course, a basic database could help to display the respective
settings and give the chance to activate / deactivate these executions.
Copying this database (flat file ?) to another box can help deploy and
upgrade: I use to copy the httpd.conf, php.ini, etc. to the new box. If I
also copied this 'post-install-scripts-permissions' to a new box, I'd only
have to execute make install // pkg_add, and everything would be in place
and activated.
Uwe
