Re: [UPDATE] print/cups enable/disable script for ro /usr mount
On Mon, Jun 15, 2015 at 02:36:49PM +0100, Craig Skinner wrote:
> 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?
Because I want to switch back and forth whenever I need to.
> Postfix doesn't renable smtpd on each stop/start.
> Does nginx do that for httpd?
This is completely different, postfix does not replace base binaries.
As I already mentioned, I don't want to have to run a script each time I
upgrade base.
> 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 (5) seconds old on
> Tue Nov 5 00:53:20 1985 GMT (measuring since the time(2) epoch).
> -- Andy Tannenbaum
>
--
Antoine
Re: [UPDATE] print/cups enable/disable script for ro /usr mount
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 (5) seconds old on
Tue Nov 5 00:53:20 1985 GMT (measuring since the time(2) epoch).
-- Andy Tannenbaum
Re: [UPDATE] print/cups enable/disable script for ro /usr mount
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).
> >
> >
>
> 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.
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.
--
Antoine
Re: [UPDATE] print/cups enable/disable script for ro /usr mount
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).
>
>
Would something like these in the PLIST automate it Antoine?
@extraexec ${TRUEPREFIX}/sbin/cups-toggle enable
@extraunexec ${TRUEPREFIX}/sbin/cups-toggle disable
Cheers.
--
Zero Defects, n.:
The result of shutting down a production line.
Re: [UPDATE] print/cups enable/disable script for ro /usr mount
On Sat, Jun 13, 2015 at 08:18:41PM +0100, Craig Skinner wrote:
> Hi there,
>
> Here's an update that enables CUPS to run on boxes which
> usually read-only mount both /usr & /usr/local
>
> The current rc script alters /usr, /etc & /dev on each start/stop.
>
> Inspiration taken from the postfix-{en,dis}able,install scripts:
> Much moved out of the rc script and into 'cups-toggle (enable|disable)'.
>
> Freely adjust to your better experience!
>
> I'm not sure if the script needs a copyright notice or not, here anyway.
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).
> ? files
> ? pkg/MESSAGE-main
> Index: Makefile
> ===
> RCS file: /cvs/ports/print/cups/Makefile,v
> retrieving revision 1.197
> diff -u -p -r1.197 Makefile
> --- Makefile 9 Jun 2015 08:01:13 - 1.197
> +++ Makefile 13 Jun 2015 18:24:58 -
> @@ -10,7 +10,7 @@ EXTRACT_SUFX= .tar.bz2
> PKGNAME-main=cups-${VERSION}
> PKGNAME-libs=cups-libs-${VERSION}
>
> -REVISION-main= 0
> +REVISION-main= 1
> REVISION-libs= 0
>
> CATEGORIES= print sysutils
> @@ -124,6 +124,8 @@ post-install:
> # Remove files now part of cups-filters
> rm -f ${PREFIX}/share/cups/banners/*
> rm -f ${PREFIX}/share/cups/data/testprint
> + ${SUBST_CMD} -c -g ${BINGRP} -o ${BINOWN} -m ${BINMODE}
> ${FILESDIR}/cups-toggle ${PREFIX}/sbin/cups-toggle
> +
>
> # Remove desktop file and icons; we don't really need them (it's just a
> # launcher for http://localhost:631 and we may actually want to
> Index: pkg/PLIST-main
> ===
> RCS file: /cvs/ports/print/cups/pkg/PLIST-main,v
> retrieving revision 1.18
> diff -u -p -r1.18 PLIST-main
> --- pkg/PLIST-main9 Jun 2015 07:39:14 - 1.18
> +++ pkg/PLIST-main13 Jun 2015 18:24:58 -
> @@ -2,6 +2,7 @@
> @conflict LPRng-*
> @pkgpath print/cups
> @pkgpath print/cups,ldap
> +@extraunexec ${TRUEPREFIX}/sbin/cups-toggle disable
> @extraunexec rm -rf ${SYSCONFDIR}/cups/*.conf.O /var/log/cups
> @bin bin/cancel
> @bin bin/cupstestdsc
> @@ -118,6 +119,7 @@ sbin/accept
> @bin sbin/cupsaccept
> @bin sbin/cupsaddsmb
> @bin sbin/cupsctl
> +sbin/cups-toggle
> @mode 0500
> @bin sbin/cupsd
> @mode
> Index: pkg/cupsd.rc
> ===
> RCS file: /cvs/ports/print/cups/pkg/cupsd.rc,v
> retrieving revision 1.21
> diff -u -p -r1.21 cupsd.rc
> --- pkg/cupsd.rc 6 Dec 2014 11:12:44 - 1.21
> +++ pkg/cupsd.rc 13 Jun 2015 18:24:58 -
> @@ -4,75 +4,27 @@
>
> daemon="${TRUEPREFIX}/sbin/cupsd"
>
> -. /etc/rc.d/rc.subr
> +. ${RCDIR}/rc.subr
>
> pexp="${daemon}"
>
> -_lpfiles="/usr/bin/lpq /usr/bin/lpr /usr/bin/lprm /usr/sbin/lpc \
> - /usr/sbin/lpd /usr/share/man/man1/lpq.1 /usr/share/man/man1/lpr.1 \
> - /usr/share/man/man1/lprm.1 /usr/share/man/man8/lpc.8 \
> - /usr/share/man/man8/lpd.8"
>
> -rc_pre() {
> - # rcexec is needed if openfiles limits are bumped and cupsd(8)
> - # runs in debug mode to prevent MaxClients warnings in logs
> - ${rcexec} "${daemon} ${daemon_flags} -t" || return 1
> - [ -e /dev/lpt0 ] && chown _cups /dev/lp[a,t][0-2]
> - # XXX cups-driverd(8) can crash when setting up a printer driver
> - rm -f /var/cache/cups/*
> -
> - if [ -e /usr/sbin/lpd.pre-cups -a ! -f /usr/sbin/lpd -a -L
> /usr/sbin/lpc ]; then
> - return
> - elif [ ! -e /usr/sbin/lpd ]; then
> - return
> - else
> - for i in ${_lpfiles}; do
> - if [ -f $i -a ! -L $i ]; then
> - mv -f $i $i.pre-cups
> - fi
> - done
> - fi
> - if [ -e /etc/printcap ]; then
> - if [ ! -e /etc/printcap.pre-cups ]; then
> - mv /etc/printcap /etc/printcap.pre-cups
> - ln -s ${SYSCONFDIR}/cups/printcap /etc/printcap
> - fi
> - else
> - ln -s ${SYSCONFDIR}/cups/printcap /etc/printcap
> - fi
> - for i in lpq lpr lprm; do
> - rm -f /usr/bin/$i
> - ln -s ${TRUEPREFIX}/bin/$i /usr/bin/$i
> +rc_pre()
> +{
> + for _lpfile in /usr/bin/lp{q,r,rm} /usr/sbin/lp{c,d}
> ${SYSCONFDIR}/printcap
> + do
> + [[ -h ${_lpfile} ]] && continue
> + print -u2 "${_lpfile} isn't a symlink - run 'cups-toggle
> enable'"
> + return 1
> done
> - rm -f /usr/sbin/lpc
> - ln -s ${TRUEPREFIX}/sbin/lpc /usr/sbin/lpc
> -}
>
> -rc_post() {
> - if [ ! -L /usr/sbin/lpc ]; then
> - return
> - else
> - for i in lpq lpr lprm; do
> - rm -f /usr/bin/$i
> - done
> -
Re: [UPDATE] print/cups enable/disable script for ro /usr mount
On 2015-06-13 Sat 20:18 PM |, 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)'.
>
So as to not clutter the last mail, here's a sample script run:
$ sudo cups-toggle enable
enable()
Backing up: lpq lpr lprm lpc lpd lpq.1 lpr.1 lprm.1 lpc.8 lpd.8.
Symlinking /etc/printcap.
Symlinking binaries: lpq lpr lprm lpc lpd.
chown_lp_devs() _cups
devices are:
crw--- 1 root wheel 16, 128 Jan 22 11:31 /dev/lpa0
crw--- 1 root wheel 16, 129 Jan 22 11:31 /dev/lpa1
crw--- 1 root wheel 16, 130 Jan 22 11:31 /dev/lpa2
crw--- 1 root wheel 16, 0 Jan 22 11:31 /dev/lpt0
crw--- 1 root wheel 16, 1 Jan 22 11:31 /dev/lpt1
crw--- 1 root wheel 16, 2 Jan 22 11:31 /dev/lpt2
devices now:
crw--- 1 _cups wheel 16, 128 Jan 22 11:31 /dev/lpa0
crw--- 1 _cups wheel 16, 129 Jan 22 11:31 /dev/lpa1
crw--- 1 _cups wheel 16, 130 Jan 22 11:31 /dev/lpa2
crw--- 1 _cups wheel 16, 0 Jan 22 11:31 /dev/lpt0
crw--- 1 _cups wheel 16, 1 Jan 22 11:31 /dev/lpt1
crw--- 1 _cups wheel 16, 2 Jan 22 11:31 /dev/lpt2
lrwxr-xr-x 1 root wheel 18 May 28 21:27 /etc/printcap@ ->
/etc/cups/printcap
lrwxr-xr-x 1 root wheel 18 May 28 21:27 /usr/bin/lpq@ ->
/usr/local/bin/lpq
-r-xr-sr-x 1 root daemon 26660 Aug 8 2014 /usr/bin/lpq.pre-cups*
lrwxr-xr-x 1 root wheel 18 May 28 21:27 /usr/bin/lpr@ ->
/usr/local/bin/lpr
-r-sr-sr-x 1 root daemon 30724 Aug 8 2014 /usr/bin/lpr.pre-cups*
lrwxr-xr-x 1 root wheel 19 May 28 21:27 /usr/bin/lprm@ ->
/usr/local/bin/lprm
lrwxr-xr-x 1 root wheel 19 May 28 21:27 /usr/bin/lprm@ ->
/usr/local/bin/lprm
-r-sr-sr-x 1 root daemon 26596 Aug 8 2014 /usr/bin/lprm.pre-cups*
-r-sr-sr-x 1 root daemon 26596 Aug 8 2014 /usr/bin/lprm.pre-cups*
lrwxr-xr-x 1 root wheel 19 May 28 21:27 /usr/sbin/lpc@ ->
/usr/local/sbin/lpc
-r-xr-sr-x 1 root daemon 37796 Aug 8 2014 /usr/sbin/lpc.pre-cups*
lrwxr-xr-x 1 root wheel 14 May 28 21:27 /usr/sbin/lpd@ -> /usr/bin/false
-r-xr-s--- 1 root daemon 72452 Aug 8 2014 /usr/sbin/lpd.pre-cups*
-r--r--r-- 1 root bin 4525 Aug 8 2014
/usr/share/man/man1/lpq.1.pre-cups
-r--r--r-- 1 root bin 7230 Aug 8 2014
/usr/share/man/man1/lpr.1.pre-cups
-r--r--r-- 1 root bin 4496 Aug 8 2014
/usr/share/man/man1/lprm.1.pre-cups
-r--r--r-- 1 root bin 5799 Aug 8 2014
/usr/share/man/man8/lpc.8.pre-cups
-r--r--r-- 1 root bin 9392 Aug 8 2014
/usr/share/man/man8/lpd.8.pre-cups
Cheers
--
Numeric stability is probably not all that important when you're guessing.
[UPDATE] print/cups enable/disable script for ro /usr mount
Hi there,
Here's an update that enables CUPS to run on boxes which
usually read-only mount both /usr & /usr/local
The current rc script alters /usr, /etc & /dev on each start/stop.
Inspiration taken from the postfix-{en,dis}able,install scripts:
Much moved out of the rc script and into 'cups-toggle (enable|disable)'.
Freely adjust to your better experience!
I'm not sure if the script needs a copyright notice or not, here anyway.
? files
? pkg/MESSAGE-main
Index: Makefile
===
RCS file: /cvs/ports/print/cups/Makefile,v
retrieving revision 1.197
diff -u -p -r1.197 Makefile
--- Makefile9 Jun 2015 08:01:13 - 1.197
+++ Makefile13 Jun 2015 18:24:58 -
@@ -10,7 +10,7 @@ EXTRACT_SUFX= .tar.bz2
PKGNAME-main= cups-${VERSION}
PKGNAME-libs= cups-libs-${VERSION}
-REVISION-main= 0
+REVISION-main= 1
REVISION-libs= 0
CATEGORIES=print sysutils
@@ -124,6 +124,8 @@ post-install:
# Remove files now part of cups-filters
rm -f ${PREFIX}/share/cups/banners/*
rm -f ${PREFIX}/share/cups/data/testprint
+ ${SUBST_CMD} -c -g ${BINGRP} -o ${BINOWN} -m ${BINMODE}
${FILESDIR}/cups-toggle ${PREFIX}/sbin/cups-toggle
+
# Remove desktop file and icons; we don't really need them (it's just a
# launcher for http://localhost:631 and we may actually want to
Index: pkg/PLIST-main
===
RCS file: /cvs/ports/print/cups/pkg/PLIST-main,v
retrieving revision 1.18
diff -u -p -r1.18 PLIST-main
--- pkg/PLIST-main 9 Jun 2015 07:39:14 - 1.18
+++ pkg/PLIST-main 13 Jun 2015 18:24:58 -
@@ -2,6 +2,7 @@
@conflict LPRng-*
@pkgpath print/cups
@pkgpath print/cups,ldap
+@extraunexec ${TRUEPREFIX}/sbin/cups-toggle disable
@extraunexec rm -rf ${SYSCONFDIR}/cups/*.conf.O /var/log/cups
@bin bin/cancel
@bin bin/cupstestdsc
@@ -118,6 +119,7 @@ sbin/accept
@bin sbin/cupsaccept
@bin sbin/cupsaddsmb
@bin sbin/cupsctl
+sbin/cups-toggle
@mode 0500
@bin sbin/cupsd
@mode
Index: pkg/cupsd.rc
===
RCS file: /cvs/ports/print/cups/pkg/cupsd.rc,v
retrieving revision 1.21
diff -u -p -r1.21 cupsd.rc
--- pkg/cupsd.rc6 Dec 2014 11:12:44 - 1.21
+++ pkg/cupsd.rc13 Jun 2015 18:24:58 -
@@ -4,75 +4,27 @@
daemon="${TRUEPREFIX}/sbin/cupsd"
-. /etc/rc.d/rc.subr
+. ${RCDIR}/rc.subr
pexp="${daemon}"
-_lpfiles="/usr/bin/lpq /usr/bin/lpr /usr/bin/lprm /usr/sbin/lpc \
- /usr/sbin/lpd /usr/share/man/man1/lpq.1 /usr/share/man/man1/lpr.1 \
- /usr/share/man/man1/lprm.1 /usr/share/man/man8/lpc.8 \
- /usr/share/man/man8/lpd.8"
-rc_pre() {
- # rcexec is needed if openfiles limits are bumped and cupsd(8)
- # runs in debug mode to prevent MaxClients warnings in logs
- ${rcexec} "${daemon} ${daemon_flags} -t" || return 1
- [ -e /dev/lpt0 ] && chown _cups /dev/lp[a,t][0-2]
- # XXX cups-driverd(8) can crash when setting up a printer driver
- rm -f /var/cache/cups/*
-
- if [ -e /usr/sbin/lpd.pre-cups -a ! -f /usr/sbin/lpd -a -L
/usr/sbin/lpc ]; then
- return
- elif [ ! -e /usr/sbin/lpd ]; then
- return
- else
- for i in ${_lpfiles}; do
- if [ -f $i -a ! -L $i ]; then
- mv -f $i $i.pre-cups
- fi
- done
- fi
- if [ -e /etc/printcap ]; then
- if [ ! -e /etc/printcap.pre-cups ]; then
- mv /etc/printcap /etc/printcap.pre-cups
- ln -s ${SYSCONFDIR}/cups/printcap /etc/printcap
- fi
- else
- ln -s ${SYSCONFDIR}/cups/printcap /etc/printcap
- fi
- for i in lpq lpr lprm; do
- rm -f /usr/bin/$i
- ln -s ${TRUEPREFIX}/bin/$i /usr/bin/$i
+rc_pre()
+{
+ for _lpfile in /usr/bin/lp{q,r,rm} /usr/sbin/lp{c,d}
${SYSCONFDIR}/printcap
+ do
+ [[ -h ${_lpfile} ]] && continue
+ print -u2 "${_lpfile} isn't a symlink - run 'cups-toggle
enable'"
+ return 1
done
- rm -f /usr/sbin/lpc
- ln -s ${TRUEPREFIX}/sbin/lpc /usr/sbin/lpc
-}
-rc_post() {
- if [ ! -L /usr/sbin/lpc ]; then
- return
- else
- for i in lpq lpr lprm; do
- rm -f /usr/bin/$i
- done
-
- rm -f /usr/sbin/lpc
-
- if [ ! -e /usr/sbin/lpd.pre-cups ]; then
- return
- else
- if [ -L /etc/printcap ]; then
- rm /etc/printcap
- fi
- for i in ${_lpfiles} /etc/printcap; do
- if [ -e $i.pre-cups ]; then
-
Re: cups-enable
One other thing: There is no man cups-enable. Also one cant get help. Personally I like to use it in /etc/rc.local to do this if links are not set, but I could not get any infos about any options - also not via cups-enable -h or cups-enable --help. regards, Thilo
Re: pkg_info message display [Re: cups-enable]
On Sat, Dec 13, 2008 at 10:38:10AM -0700, Theo de Raadt wrote: > > .It Fl M > > Show the install-message file (if any) for each package. > > +If any step not documented in the manual must be taken before a package > > +can be used, this file will often mention it. > > That is an attempt to entirely push the problem under the table. > > The default message should be relevant. Noone will use special > options to go look for relevant information. As an option, it would > be much more realistic if -M did not EXIST. > > The basics + by-hand-setup information for most things is 2 lines > long, because it points at a file. That is what should be printed > everytime. Making people go dig for the important information they > need is retarded. Yeah, you're right, and that corresponds to what I was thinking. Giving further messages to people such as "oh, you also need to look there" is stupid. I'm of the opinion I'm going to consider INSTALL messages as part of the description (a part that gets shown during installation), and show them whenever we ask for the description (unless we're in the "special" programmer's mode that shows stuff in a way not suitable for humans). That said, as we discussed already, I'm quite aware that package tools are often too wordy, and I hope to be able to address that in the not so distant future. One thing people can definitely do to help is track down useless verbiage: DESCR don't have to mention obvious things. Neither do MESSAGES. If you can remove useless stuff, then USEFUL things will jump at the face of the user, and that's always a good thing. ;-)
Re: cups-enable
On Sun, 14 Dec 2008, Jacob Meuser wrote: > > I think it would also be nice if README.OpenBSD were in pkg/ dirs > and handled automatically, kinda like MESSAGE is now. adding files/ > dirs seems like a waste. I like this. -- Antoine
Re: cups-enable
On Sat, Dec 13, 2008 at 09:15:46PM -0500, Steve Shockley wrote: > On 12/12/2008 2:40 PM, Jacob Meuser wrote: >>> Who knows about -M? I'm serious. I've never used that option before, >>> and it's totally nonobvious that I should look through the man page to >>> find it. >> >> uh, you're saying it's totally nonobvious that people should read the >> manuals of tools they are using? > > In my case, I didn't know it existed, I always just looked at the + > files in /var/db/pkg (which is far less intuitive than -M, but I already > knew they were there). > > Perhaps pkg_info packagename should note the existence of a > README.OpenBSD if one exists? imo having them under PREFIX/share/doc/pkgname makes them hard to find, whereas PREFIX/share/README.OpenBSD/pkgname (where pkgname is the actual file of info) would be imo easy enough to find that we wouldn't have to say whether it exists and where to find it if so. I think it would also be nice if README.OpenBSD were in pkg/ dirs and handled automatically, kinda like MESSAGE is now. adding files/ dirs seems like a waste. unfortnately, I have already mailed my wishlist to Santa ... got some audio stuff and a uvideo, but no pkg patches :( -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: cups-enable
On 12/12/2008 2:40 PM, Jacob Meuser wrote: Who knows about -M? I'm serious. I've never used that option before, and it's totally nonobvious that I should look through the man page to find it. uh, you're saying it's totally nonobvious that people should read the manuals of tools they are using? In my case, I didn't know it existed, I always just looked at the + files in /var/db/pkg (which is far less intuitive than -M, but I already knew they were there). Perhaps pkg_info packagename should note the existence of a README.OpenBSD if one exists?
Re: pkg_info message display [Re: cups-enable]
> .It Fl M > Show the install-message file (if any) for each package. > +If any step not documented in the manual must be taken before a package > +can be used, this file will often mention it. That is an attempt to entirely push the problem under the table. The default message should be relevant. Noone will use special options to go look for relevant information. As an option, it would be much more realistic if -M did not EXIST. The basics + by-hand-setup information for most things is 2 lines long, because it points at a file. That is what should be printed everytime. Making people go dig for the important information they need is retarded. Documenting that they need to do such a ridiculous process is not right.
Re: pkg_info message display [Re: cups-enable]
Ted Unangst wrote on Fri, Dec 12, 2008 at 05:20:19PM -0500: > Why would I know to use -M? Because I read the man page and want to > see the "install-message file"? I already installed the damn thing, > so obviously I don't want to see that file. The install message is not a "message explaining how to install", but a "message to read after install", in order to put "the damn thing" in production. Strangely, there is little information in the man pages (1) What a ports maintainer should put into pkg/MESSAGE, except for half a sentence in pkg_create(1), option -M: "Useful for things like legal notices on almost-free software, etc." The porting checklist on the web page says little, either. (2) What a user might expect to find in an install message. In particular, this might be useful to decide whether or not to use -M. I'm aware of the ongoing discussion concerning merits and problems of +DISPLAY files (and i agree some are rather bloaty, and i share the bad habit of heeding them little because they are so numerous), but for the time being, it might help to tell users (like tedu@ ;-) what to expect with the current state of affairs: Index: pkg_info.1 === RCS file: /cvs/src/usr.sbin/pkg_add/pkg_info.1,v retrieving revision 1.30 diff -u -r1.30 pkg_info.1 --- pkg_info.1 26 Oct 2008 16:16:37 - 1.30 +++ pkg_info.1 13 Dec 2008 17:15:14 - @@ -138,6 +138,8 @@ This lets you add a special token to the start of each field. .It Fl M Show the install-message file (if any) for each package. +If any step not documented in the manual must be taken before a package +can be used, this file will often mention it. .It Fl P Show the pkgpath for each package. You can easily build a subdirlist with this.
Re: pkg_info message display [Re: cups-enable]
On Sat, 13 Dec 2008, Jacob Meuser wrote:
> how is "too big" defined? is the above abbreviated CUPS message too
> big to add to the default pkg_info output?
At one point I was told that too big = >15 lines.
> how about a standard directory for README.OpenBSD files?
> ${PREFIX}/share/README.OpenBSD/port-x.y ? and then move the majority
> of this stuff there? I think this would make such files much easier
> to find.
This is interesting idea actually.
> of course, I'm responsible for some of these MESSAGE files. I really
> do see the "noise" during install/upgrade as a problem, as people
> (including myself) probably don't always read it, even though
> ignoring it can lead to problems ...
If pkg tools could be changed so that the spam from running @exec
command in PLIST could be removed, it would already be an improvement. I
understand the purpose of these warnings but I think the tools are now
mature enough to remove the warnings and only enable them when -v is
used for e.g.
--
Antoine
Re: pkg_info message display [Re: cups-enable]
On Sat, Dec 13, 2008 at 10:10:26AM +0100, Landry Breuil wrote:
> On Fri, Dec 12, 2008 at 11:27:44PM -0600, Marco Peereboom wrote:
> > Ted is right. I do know about -M but I use it so frequently that I
> > always have to find it in the man. pkg_info could should be able to
> > display this info like pkg_info cups. That makes intuitive sense to me
> > and I think others as well.
>
> pkg_info displays package _information_, which is terse. pkg_info -M
> displays additional information about how to use the given package, only
> if it's needed,
there are 300 MESSAGE files in ports ...
> and it can be sometimes big
I think some is outright bloat. take the cups MESSAGE for example:
>>>
To enable CUPS, execute '${PREFIX}/sbin/cups-enable' as root.
To disable CUPS, execute '${PREFIX}/sbin/cups-disable' as root.
To start cups at boot time, add the following to
/etc/rc.local:
if [ -x ${PREFIX}/sbin/cupsd ]; then
echo -n ' cupsd'; ${PREFIX}/sbin/cupsd
fi
Starting cupsd will overwrite /etc/printcap. A backup copy of this file
is saved as /etc/printcap.pre-cups by '${PREFIX}/sbin/cups-enable'
and will be restored when you run '${PREFIX}/sbin/cups-disable'.
<<<
is it really necessary to have an example for rc.local? isn't it going
to be more-or-less the same for all daemons? sometimes there are
exceptions, but shouldn't this stuff be covered in manuals? is all
the info in these MESSAGE files really needed?
couldn't the CUPS message be shortened to something like:
Starting cupsd will overwrite /etc/printcap. CUPS has "replacement"
programs for some system programs. ${PREFIX}/sbin/cups-enable
can be used to backup the current printcap and system programs.
${PREFIX}/sbin/cups-enable can be used to restore them.
> (and when too big, separated
how is "too big" defined? is the above abbreviated CUPS message too
big to add to the default pkg_info output?
> in a given README.OpenBSD, which pkg_info -M points to).
how about a standard directory for README.OpenBSD files?
${PREFIX}/share/README.OpenBSD/port-x.y ? and then move the majority
of this stuff there? I think this would make such files much easier
to find.
of course, I'm responsible for some of these MESSAGE files. I really
do see the "noise" during install/upgrade as a problem, as people
(including myself) probably don't always read it, even though
ignoring it can lead to problems ...
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Re: pkg_info message display [Re: cups-enable]
* Landry Breuil wrote: [...] > about. But i think sthen@'s proposal to add a message like 'This package > has additional information, view it with pkg_info -M' is the most > 'user-friendly'. Yes, I'd second that.
Re: pkg_info message display [Re: cups-enable]
On Fri, Dec 12, 2008 at 11:27:44PM -0600, Marco Peereboom wrote: > Ted is right. I do know about -M but I use it so frequently that I > always have to find it in the man. pkg_info could should be able to > display this info like pkg_info cups. That makes intuitive sense to me > and I think others as well. pkg_info displays package _information_, which is terse. pkg_info -M displays additional information about how to use the given package, only if it's needed, and it can be sometimes big (and when too big, separated in a given README.OpenBSD, which pkg_info -M points to). To me, it doesn't make any sense to display both when running pkg_info without funky flags. I just want to know what is the given package about. But i think sthen@'s proposal to add a message like 'This package has additional information, view it with pkg_info -M' is the most 'user-friendly'. Landry
Re: pkg_info message display [Re: cups-enable]
Ted is right. I do know about -M but I use it so frequently that I always have to find it in the man. pkg_info could should be able to display this info like pkg_info cups. That makes intuitive sense to me and I think others as well. On Fri, Dec 12, 2008 at 11:00:20PM +0100, Marc Espie wrote: > On Fri, Dec 12, 2008 at 04:40:23PM -0500, Ted Unangst wrote: > > On Fri, Dec 12, 2008 at 2:31 PM, Marc Espie wrote: > > >> These are too easy to miss at some point after installation. > > >> What does anyone think about doing something like this? > > > > > > Blech > > > > > > The issue is mostly to have less stuff displayed during installation, > > > which > > > is not yet done, but should be. > > > > The problem wasn't that I missed the message during installation, it's > > that I couldn't find the message 8 months later. Now that I know > > about -M, I can probably remember to use it, but it's a lot less > > intuitive than plain pkg_info providing me with what I'd consider some > > pretty critical information about the port. > > Wow. > > Like, gcc tells you to use -W -Wall if you forget to mention them ? > Or sh tells you to use set -e whenever it runs a shell script ? >
Re: pkg_info message display [Re: cups-enable]
On Fri, Dec 12, 2008 at 5:00 PM, Marc Espie wrote: > Like, gcc tells you to use -W -Wall if you forget to mention them ? > Or sh tells you to use set -e whenever it runs a shell script ? Duh, of course not. But why am I running pkg_info? Because I want *info*. That's the whole freaking purpose of the program. So why does it make me beg pretty please to print some basic info? Of all the reasons I might have to run pkg_info cups after installation, to find out about cups-enable is the #1 reason I would do so. Why would I know to use -M? Because I read the man page and want to see the "install-message file"? I already installed the damn thing, so obviously I don't want to see that file.
Re: pkg_info message display [Re: cups-enable]
On Fri, Dec 12, 2008 at 04:40:23PM -0500, Ted Unangst wrote: > On Fri, Dec 12, 2008 at 2:31 PM, Marc Espie wrote: > >> These are too easy to miss at some point after installation. > >> What does anyone think about doing something like this? > > > > Blech > > > > The issue is mostly to have less stuff displayed during installation, which > > is not yet done, but should be. > > The problem wasn't that I missed the message during installation, it's > that I couldn't find the message 8 months later. Now that I know > about -M, I can probably remember to use it, but it's a lot less > intuitive than plain pkg_info providing me with what I'd consider some > pretty critical information about the port. Wow. Like, gcc tells you to use -W -Wall if you forget to mention them ? Or sh tells you to use set -e whenever it runs a shell script ?
Re: pkg_info message display [Re: cups-enable]
On Fri, Dec 12, 2008 at 08:31:07PM +0100, Marc Espie wrote: > On Fri, Dec 12, 2008 at 09:50:15AM +, Stuart Henderson wrote: > > On 2008/12/12 08:06, Marc Balmer wrote: > > > > > > > > It's also not mentioned by pkg_info as something of interest. It > > > > should be, right? > > > > > > Your are wrong. When you install CUPS, a message is displayed. > > > That message can be redisplayed at any time using 'pkg_info -M cups'. > > > > These are too easy to miss at some point after installation. > > What does anyone think about doing something like this? > > Blech > > The issue is mostly to have less stuff displayed during installation, which > is not yet done, but should be. > > If packages show useless messages, then they're bad. > > You can always do > pkg_info -M /var/db/pkg/* > to make sure you didn't miss anything. > > > jikes' message is ways too long, btw, and not even right, since *users* will > not see it. > might it be beter to just display this all by default with pkg_info, and not at all with pkg_add, leaving pkg_add messages truely about packaging issues instead of both packaging issues and operational issues? along with trimming out the useless stuff, of course. just an idea. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: pkg_info message display [Re: cups-enable]
On Fri, Dec 12, 2008 at 2:31 PM, Marc Espie wrote: >> These are too easy to miss at some point after installation. >> What does anyone think about doing something like this? > > Blech > > The issue is mostly to have less stuff displayed during installation, which > is not yet done, but should be. The problem wasn't that I missed the message during installation, it's that I couldn't find the message 8 months later. Now that I know about -M, I can probably remember to use it, but it's a lot less intuitive than plain pkg_info providing me with what I'd consider some pretty critical information about the port.
Re: cups-enable
On Fri, Dec 12, 2008 at 09:58:01PM +0100, Antoine Jacoutot wrote: > On Fri, 12 Dec 2008, Jacob Meuser wrote: > > > On Fri, Dec 12, 2008 at 09:48:35PM +0100, Antoine Jacoutot wrote: > > > On Fri, 12 Dec 2008, Jacob Meuser wrote: > > > > one last note: pretty much every driver that can be used with cups > > > > can be used with base lpd, it's just a little more work ... imo the > > > > > > This is true except it is much more complicated to pass options to stock > > > lpd than it is for cups if I want e.g. a4 with photo color and duplex. > > > > I used to set up a few printcap entries for the same printer: lp, > > scratch, photo, p4up. > > Exactly, that was my point :-) > It works fine, it's just not very intuivive. that's the classic lpd approach, if i'm not mistaken. didn't this thread start off with complaints about things being non-intuitive? anyway ... I think the following isn't such a bad idea. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org Index: files/cups-enable ======= RCS file: /home2/cvs/OpenBSD/ports/print/cups/files/cups-enable,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 cups-enable --- files/cups-enable 16 Jan 2005 12:36:42 - 1.1.1.1 +++ files/cups-enable 12 Dec 2008 21:21:44 - @@ -28,10 +28,30 @@ ## if [ -e /usr/sbin/lpd.pre-cups ]; then -echo "lpd already preserved, not saving old files." +echo "Backed up files exist. Continuing this script will overwrite" +echo "system files without saving them." +echo -n "Are you sure you want to continue (y/[n])? " + +read answer +echo "" + +if [ X$answer != Xy ]; then +echo "exit" +exit +fi + echo "" elif [ ! -e /usr/sbin/lpd ]; then echo "Couldn't find lpd files, not saving old files." +echo -n "Are you sure you want to continue (y/[n])? " + +read answer +echo "" + +if [ X$answer != Xy ]; then + echo "exit" + exit +fi echo "" else echo "Trying to save lpd files:"
Re: cups-enable
On Fri, 12 Dec 2008, Jacob Meuser wrote: > On Fri, Dec 12, 2008 at 09:48:35PM +0100, Antoine Jacoutot wrote: > > On Fri, 12 Dec 2008, Jacob Meuser wrote: > > > one last note: pretty much every driver that can be used with cups > > > can be used with base lpd, it's just a little more work ... imo the > > > > This is true except it is much more complicated to pass options to stock > > lpd than it is for cups if I want e.g. a4 with photo color and duplex. > > I used to set up a few printcap entries for the same printer: lp, > scratch, photo, p4up. Exactly, that was my point :-) It works fine, it's just not very intuivive. -- Antoine
Re: cups-enable
On Fri, Dec 12, 2008 at 09:48:35PM +0100, Antoine Jacoutot wrote: > On Fri, 12 Dec 2008, Jacob Meuser wrote: > > one last note: pretty much every driver that can be used with cups > > can be used with base lpd, it's just a little more work ... imo the > > This is true except it is much more complicated to pass options to stock > lpd than it is for cups if I want e.g. a4 with photo color and duplex. I used to set up a few printcap entries for the same printer: lp, scratch, photo, p4up. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: cups-enable
On Fri, 12 Dec 2008, Jacob Meuser wrote: > one last note: pretty much every driver that can be used with cups > can be used with base lpd, it's just a little more work ... imo the This is true except it is much more complicated to pass options to stock lpd than it is for cups if I want e.g. a4 with photo color and duplex. -- Antoine
Re: cups-enable
On Fri, Dec 12, 2008 at 03:08:03PM +0100, Artur Grabowski wrote: > Marc Balmer writes: > > > Your are wrong. When you install CUPS, a message is displayed. > > That message can be redisplayed at any time using 'pkg_info -M cups'. > > Is this like Postfix where postfix is disabled by pkg_add -u and the > message about enabling it drowns in the bazillion of lines about > rebuilding icons or whatever that spam is about? > > Sorry. but a few lines with "Hi, we just disabled your production > critical service. you have to enable it again" hidden in spam about > rebuilding some xml crap, icon databases and whatever is not good. > > I think postfix was fixed to not break this way (at least it didn't > shut down when I upgraded a few hours ago), if this is the issue with > cups, it should be fixed too. actually, it's upgrading base that is likely to break cups, assuming you rely on cups-enable and not come up with your own solution. cups-enable is not run automatically when the package is added. we don't want to overwrite system binaries by default, right? keep in mind this discussion started with someone not being able to find the script that would put them in such a situation. cups-enable is there as a convenience. there are other ways to deal with cups. but those require some thought on the part of the sysadmin. I posted the link to the original discussion about this script for a reason. you have a point about too much noise when installing/upgrading, but it has been improved at least a little. all the "important" message are displayed at the end and not mixed in with the icon/xml update "spam". one last note: pretty much every driver that can be used with cups can be used with base lpd, it's just a little more work ... imo the best solution is to implement ipp in lpd and tell cups to screw off since it would really not be offering more than the convenience/ headache dichotomy we are discussing, but that is just me. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: cups-enable
On Fri, Dec 12, 2008 at 09:46:32AM -0500, Ted Unangst wrote: > On Fri, Dec 12, 2008 at 2:06 AM, Marc Balmer wrote: > >> It's also not mentioned by pkg_info as something of interest. It > >> should be, right? > > > > Your are wrong. When you install CUPS, a message is displayed. > > That message can be redisplayed at any time using 'pkg_info -M cups'. > > Who knows about -M? I'm serious. I've never used that option before, > and it's totally nonobvious that I should look through the man page to > find it. uh, you're saying it's totally nonobvious that people should read the manuals of tools they are using? -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: pkg_info message display [Re: cups-enable]
On Fri, Dec 12, 2008 at 09:50:15AM +, Stuart Henderson wrote: > On 2008/12/12 08:06, Marc Balmer wrote: > > > > > > It's also not mentioned by pkg_info as something of interest. It > > > should be, right? > > > > Your are wrong. When you install CUPS, a message is displayed. > > That message can be redisplayed at any time using 'pkg_info -M cups'. > > These are too easy to miss at some point after installation. > What does anyone think about doing something like this? Blech The issue is mostly to have less stuff displayed during installation, which is not yet done, but should be. If packages show useless messages, then they're bad. You can always do pkg_info -M /var/db/pkg/* to make sure you didn't miss anything. jikes' message is ways too long, btw, and not even right, since *users* will not see it.
Re: pkg_info message display [Re: cups-enable]
On Fri, Dec 12, 2008 at 4:50 AM, Stuart Henderson wrote: > On 2008/12/12 08:06, Marc Balmer wrote: >> > >> > It's also not mentioned by pkg_info as something of interest. It >> > should be, right? >> >> Your are wrong. When you install CUPS, a message is displayed. >> That message can be redisplayed at any time using 'pkg_info -M cups'. > > These are too easy to miss at some point after installation. > What does anyone think about doing something like this? that would have saved a ton of effort.
Re: cups-enable
On Fri, Dec 12, 2008 at 2:06 AM, Marc Balmer wrote: >> It's also not mentioned by pkg_info as something of interest. It >> should be, right? > > Your are wrong. When you install CUPS, a message is displayed. > That message can be redisplayed at any time using 'pkg_info -M cups'. Who knows about -M? I'm serious. I've never used that option before, and it's totally nonobvious that I should look through the man page to find it.
Re: cups-enable
Marc Balmer writes: > Your are wrong. When you install CUPS, a message is displayed. > That message can be redisplayed at any time using 'pkg_info -M cups'. Is this like Postfix where postfix is disabled by pkg_add -u and the message about enabling it drowns in the bazillion of lines about rebuilding icons or whatever that spam is about? Sorry. but a few lines with "Hi, we just disabled your production critical service. you have to enable it again" hidden in spam about rebuilding some xml crap, icon databases and whatever is not good. I think postfix was fixed to not break this way (at least it didn't shut down when I upgraded a few hours ago), if this is the issue with cups, it should be fixed too. //art
Re: pkg_info message display [Re: cups-enable]
On Fri, Dec 12, 2008 at 09:50:15AM +, Stuart Henderson wrote:
> On 2008/12/12 08:06, Marc Balmer wrote:
> > >
> > > It's also not mentioned by pkg_info as something of interest. It
> > > should be, right?
> >
> > Your are wrong. When you install CUPS, a message is displayed.
> > That message can be redisplayed at any time using 'pkg_info -M cups'.
>
> These are too easy to miss at some point after installation.
> What does anyone think about doing something like this?
seems simple and helpful to me.
> ...
> Index: pkg_info
> ===
> RCS file: /data/cvsroot/open/anoncvs/cvs/src/usr.sbin/pkg_add/pkg_info,v
> retrieving revision 1.70
> diff -u -p -r1.70 pkg_info
> --- pkg_info 26 Oct 2008 16:16:37 - 1.70
> +++ pkg_info 12 Dec 2008 09:44:17 -
> @@ -139,6 +139,10 @@ sub print_description
> print;
> }
> close $fh;
> +
> + if (-f $dir.DISPLAY) {
> + print "This package has an installation message.";
> + }
> }
>
> sub get_line
> ...
>
> I didn't put too much thought into the wording, I intend it as
> a quick diff to illustrate the discussion rather than to commit
> directly - maybe we want to also mention other things like
> UNDISPLAY, etc. Or maybe it /is/ fine just like this.
>
--
jake...@sdf.lonestar.org
SDF Public Access UNIX System - http://sdf.lonestar.org
Re: pkg_info message display [Re: cups-enable]
* Stuart Henderson wrote:
> On 2008/12/12 08:06, Marc Balmer wrote:
> > >
> > > It's also not mentioned by pkg_info as something of interest. It
> > > should be, right?
> >
> > Your are wrong. When you install CUPS, a message is displayed.
> > That message can be redisplayed at any time using 'pkg_info -M cups'.
>
> These are too easy to miss at some point after installation.
> What does anyone think about doing something like this?
They obviously are... I think we should maybe indeed have such
an indication of some sort.
>
> ...
> Index: pkg_info
> ===
> RCS file: /data/cvsroot/open/anoncvs/cvs/src/usr.sbin/pkg_add/pkg_info,v
> retrieving revision 1.70
> diff -u -p -r1.70 pkg_info
> --- pkg_info 26 Oct 2008 16:16:37 - 1.70
> +++ pkg_info 12 Dec 2008 09:44:17 -
> @@ -139,6 +139,10 @@ sub print_description
> print;
> }
> close $fh;
> +
> + if (-f $dir.DISPLAY) {
> + print "This package has an installation message.";
> + }
> }
>
> sub get_line
> ...
>
> I didn't put too much thought into the wording, I intend it as
> a quick diff to illustrate the discussion rather than to commit
> directly - maybe we want to also mention other things like
> UNDISPLAY, etc. Or maybe it /is/ fine just like this.
>
--
Marc Balmer, Micro Systems, Wiesendamm 2a, Postfach, CH-4019 Basel, Switzerland
http://www.msys.ch/ http://www.vnode.ch/ "In God we trust, in C we code."
pkg_info message display [Re: cups-enable]
On 2008/12/12 08:06, Marc Balmer wrote:
> >
> > It's also not mentioned by pkg_info as something of interest. It
> > should be, right?
>
> Your are wrong. When you install CUPS, a message is displayed.
> That message can be redisplayed at any time using 'pkg_info -M cups'.
These are too easy to miss at some point after installation.
What does anyone think about doing something like this?
...
Index: pkg_info
===
RCS file: /data/cvsroot/open/anoncvs/cvs/src/usr.sbin/pkg_add/pkg_info,v
retrieving revision 1.70
diff -u -p -r1.70 pkg_info
--- pkg_info26 Oct 2008 16:16:37 - 1.70
+++ pkg_info12 Dec 2008 09:44:17 -
@@ -139,6 +139,10 @@ sub print_description
print;
}
close $fh;
+
+ if (-f $dir.DISPLAY) {
+ print "This package has an installation message.";
+ }
}
sub get_line
...
I didn't put too much thought into the wording, I intend it as
a quick diff to illustrate the discussion rather than to commit
directly - maybe we want to also mention other things like
UNDISPLAY, etc. Or maybe it /is/ fine just like this.
Re: cups-enable
* Ted Unangst wrote: > wondering why things stopped working after an upgrade, it took me a > little while to remember that lpr was overwritten. but then it took a > while longer to find cups-enable, even after I remembered that I > needed to run it, because it's not cupsenable, which is the only one > that shows up when I type cups[tab]. I spent a good amount of time > trying to find a program with a name just like cupsenable but that > wasn't cupsenable. > > Why is cups-enable installed only runnable by root? It's harder to > find this way. And why can't a normal user even read it? It already > checks that you're root before doing anything, and we have tons of > things that aren't useful to users but are still runnable. > > It's also not mentioned by pkg_info as something of interest. It > should be, right? Your are wrong. When you install CUPS, a message is displayed. That message can be redisplayed at any time using 'pkg_info -M cups'. > While on the subject, the lpd.pre-cups test is a little broken. I had > my old lpd backed up (pre-upgrade). Now the 4.4 tools are gone, and > the backups are from 4.3 or whenever. -- Marc Balmer, Micro Systems, Wiesendamm 2a, Postfach, CH-4019 Basel, Switzerland http://www.msys.ch/ http://www.vnode.ch/ "In God we trust, in C we code."
Re: cups-enable
On Fri, Dec 12, 2008 at 05:33:17AM +, Jacob Meuser wrote: > On Fri, Dec 12, 2008 at 12:00:21AM -0500, Ted Unangst wrote: > > While on the subject, the lpd.pre-cups test is a little broken. I had > > my old lpd backed up (pre-upgrade). Now the 4.4 tools are gone, and > > the backups are from 4.3 or whenever. > > well, it's been like that for close to 4 years now. http://marc.info?l=openbsd-ports&m=104153716826223&w=2 for a bit of history on how this script came to be. only searched because I vaguely remembered that discussion. -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
Re: cups-enable
On Fri, Dec 12, 2008 at 12:00:21AM -0500, Ted Unangst wrote: > wondering why things stopped working after an upgrade, it took me a > little while to remember that lpr was overwritten. but then it took a > while longer to find cups-enable, even after I remembered that I > needed to run it, because it's not cupsenable, which is the only one > that shows up when I type cups[tab]. I spent a good amount of time > trying to find a program with a name just like cupsenable but that > wasn't cupsenable. pkg_info -L cups | grep enable > Why is cups-enable installed only runnable by root? It's harder to > find this way. And why can't a normal user even read it? It already > checks that you're root before doing anything, and we have tons of > things that aren't useful to users but are still runnable. good point. > It's also not mentioned by pkg_info as something of interest. It > should be, right? pkg_info -M cups this message is also displayed when cups is installed. > While on the subject, the lpd.pre-cups test is a little broken. I had > my old lpd backed up (pre-upgrade). Now the 4.4 tools are gone, and > the backups are from 4.3 or whenever. well, it's been like that for close to 4 years now. anyway, how will the script know if the backed-up files are from a previous release? should the backups use `uname -r` in their names? or if it finds a backed-up file, should it ask again if you're sure you want to continue? -- jake...@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org
cups-enable
wondering why things stopped working after an upgrade, it took me a little while to remember that lpr was overwritten. but then it took a while longer to find cups-enable, even after I remembered that I needed to run it, because it's not cupsenable, which is the only one that shows up when I type cups[tab]. I spent a good amount of time trying to find a program with a name just like cupsenable but that wasn't cupsenable. Why is cups-enable installed only runnable by root? It's harder to find this way. And why can't a normal user even read it? It already checks that you're root before doing anything, and we have tons of things that aren't useful to users but are still runnable. It's also not mentioned by pkg_info as something of interest. It should be, right? While on the subject, the lpd.pre-cups test is a little broken. I had my old lpd backed up (pre-upgrade). Now the 4.4 tools are gone, and the backups are from 4.3 or whenever.
