On 2015-06-14 Sun 08:36 AM |, Antoine Jacoutot wrote:
> On Sat, Jun 13, 2015 at 10:31:28PM +0100, Craig Skinner wrote:
> > On 2015-06-13 Sat 22:39 PM |, Antoine Jacoutot wrote:
> > > On Sat, Jun 13, 2015 at 08:18:41PM +0100, Craig Skinner wrote:
> > > >
> > > > Inspiration taken from the postfix-{en,dis}able,install scripts:
> > > > Much moved out of the rc script and into 'cups-toggle (enable|disable)'.
> > > >
> > >
> > > I prefer the way it's done now.
> > > It's automatic -- I don't want to have to remember to run yet another
> > > command each time I update (which is very often).
> > >
> > >
As the changes made to /dev, /etc & /usr by either script aren't in
PLIST, they should be OK during an upgrade.
The /usr symlinks just point to upgraded files in /usr/local
Ownership of the /dev items wont matter.
/etc/printcap isn't in PLIST as it's a symlink to a cups generated file.
So once cups-toggle is run once, /usr can be mounted read only.
And then /usr/local after the install/upgrade too.
Also /usr, /dev & /etc aren't altered with each reboot.
> >
> > Would something like these in the PLIST automate it Antoine?
> >
> > @extraexec ${TRUEPREFIX}/sbin/cups-toggle enable
> > @extraunexec ${TRUEPREFIX}/sbin/cups-toggle disable
>
> No because that means it will run at pkg_add time -- which is not good at all.
In that case, is the MESSAGE better?
As 'cups-toggle disable' needs run before cups-toggle is removed,
I put in an @extraunexec rather than an UNMESSAGE.
> At least with the rc.d script it makes sense: if I want to start cups, then I
> obviously want it to replace lpd the time it is running. And when I stop it,
> lpd is back.
>
Sorry Antoine,... I don't understand;-
If CUPS has been set up as the printing system,
why would lpd be needed back regularily on a production host?
Postfix doesn't renable smtpd on each stop/start.
Does nginx do that for httpd?
I don't run that many daemons. Are there other base replacing daemons
which do this enable/disable dance each stop/start?
Confused.
--
UNIX was half a billion (500000000) seconds old on
Tue Nov 5 00:53:20 1985 GMT (measuring since the time(2) epoch).
-- Andy Tannenbaum
