From sacadmin Thu Jun 21 10:07:02 2007 Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5LH72Ug004479; Thu, 21 Jun 2007 10:07:02 -0700 (PDT) Received: (from johnf@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id l5LH7231004475; Thu, 21 Jun 2007 10:07:02 -0700 (PDT) Date: Thu, 21 Jun 2007 10:07:02 -0700 (PDT) From: John Fischer Message-Id: <200706211707.l5LH7231004475@sac.sfbay.sun.com> To: PSARC-record@sac.sfbay.sun.com Cc: Dermot.McCluskey@Sun.COM Subject: Info directory file update service [PSARC/2007/375 FastTrack timeout 06/28/2007] Status: RO Content-Length: 580 Template Version: @(#)sac_nextcase 1.63 06/14/07 SMI This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Info directory file update service 1.2. Name of Document Author/Supplier: Author: Dermot McCluskey 1.3 Date of This Document: 21 June, 2007 4. Technical Description See the case directory for more detail 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: JDS - Gnome 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From John.Fischer@Sun.COM Thu Jun 21 10:16:46 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5LHGk3T004686 for ; Thu, 21 Jun 2007 10:16:46 -0700 (PDT) Received: from brmea-mail-1.sun.com (brmea-mail-1.Sun.COM [192.18.98.31]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5LHF8RQ016591 for ; Thu, 21 Jun 2007 10:15:08 -0700 (PDT) Received: from fe-amer-10.sun.com ([192.18.108.184]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5LHF84F022080 for ; Thu, 21 Jun 2007 17:15:08 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJZ00701X6B1100@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Thu, 21 Jun 2007 11:15:08 -0600 (MDT) Received: from 129.145.154.105 ([129.145.154.105]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJZ00MX7X8JFWBC@mail-amer.sun.com> for PSARC-ext@sac.sfbay.sun.com; Thu, 21 Jun 2007 11:14:44 -0600 (MDT) Date: Thu, 21 Jun 2007 10:14:43 -0700 From: John Fischer Subject: IPSARC/2007/375 - Info directory file update service Sender: John.Fischer@Sun.COM To: PSARC-ext@sac.sfbay.sun.com Cc: John Fischer , Dermot McCluskey Reply-to: John.Fischer@Sun.COM Message-id: <1182446083.52470.8.camel@sr1-umpk-55> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301c Content-type: multipart/mixed; boundary="Boundary_(ID_b0+f/FjsXhWbOFp/7jiDew)" Status: RO Content-Length: 2328 --Boundary_(ID_b0+f/FjsXhWbOFp/7jiDew) Content-type: text/plain Content-transfer-encoding: 7BIT PSARC, I am sponsoring this project for Dermot McCluskey of the JDS group in Dublin Ireland. The case directory contains this proposal. I have set the timer for Thursday June 28th, 2007. This project is supplying a transient SMF service that rebuilds the Info doc directory files. The project is requesting a Patch release binding for Solaris. Thanks, John --Boundary_(ID_b0+f/FjsXhWbOFp/7jiDew) Content-type: text/plain; charset=ASCII; name=proposal.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=proposal.txt Info directory file update service 1. Summary This fast-track introduces the Info directory file update service, an SMF service which maintains directory files for Info documents. Patch release binding is requested. 2. Discussion GNU Manual files in the Info format are typically accompanied by a directory file which provides the user with a menu of the topics for which manuals are available. In the SFW consolidation, Info documents are located in /usr/sfw/share/info and /usr/share/info and each location includes its own directory file, called "dir", covering all the Info docs at that location. Currently, the directory files are generated at build-time using the "install-info" utility provided by texinfo(4). All the Info documents and the accompanying directory files for the consolidation are then delivered together (in SUNWsfinf). The problem is that we now wish to deliver the Info docs separately, as part of the relevant package. Also, other consolidations, such as JDS, may wish to install additional Info docs in the same locations and will therefore need to update the directory files. Install and remove Class Action Scripts that replicate the work of install-info would prove excessively complex and so a transient SMF service that rebuilds the directory file when any Info docs are installed, removed or modified is now proposed. This service will use the existing "Software Installation" RBAC rights profile. 3. Interfaces Exported Interfaces =================== svc:/application/update/infodir:default Committed FRMI application/info_dir_path Committed Property --Boundary_(ID_b0+f/FjsXhWbOFp/7jiDew)-- From carlsonj@phorcys.east.sun.com Thu Jun 21 10:28:25 2007 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5LHSOEq005176 for ; Thu, 21 Jun 2007 10:28:25 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.1+Sun/8.14.1) with ESMTP id l5LHQkDo022516; Thu, 21 Jun 2007 13:26:46 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.1+Sun/8.14.1/Submit) id l5LHQkGa022513; Thu, 21 Jun 2007 13:26:46 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18042.46293.964044.369931@gargle.gargle.HOWL> Date: Thu, 21 Jun 2007 13:26:45 -0400 From: James Carlson To: John.Fischer@Sun.COM Cc: PSARC-ext@sac.sfbay.sun.com, Dermot McCluskey Subject: Re: IPSARC/2007/375 - Info directory file update service In-Reply-To: <1182446083.52470.8.camel@sr1-umpk-55> References: <1182446083.52470.8.camel@sr1-umpk-55> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 592 John Fischer writes: > application/info_dir_path Committed Property Do you have any documentation on how this value works? Is it a $PATH-like object (colon-separated set of directories) or something else? What does the service depend on? (I would guess svc:/system/filesystem/local:default, but I'm not sure.) A draft man page might make some of this clearer. -- James Carlson, Solaris Networking Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From gww@eng.sun.com Thu Jun 21 10:36:57 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5LHav9r005401 for ; Thu, 21 Jun 2007 10:36:57 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5LHZHXE004811; Thu, 21 Jun 2007 10:35:17 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5LHc51p025040; Thu, 21 Jun 2007 10:38:05 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5LHc5XM025039; Thu, 21 Jun 2007 10:38:05 -0700 (PDT) Date: Thu, 21 Jun 2007 10:38:05 -0700 (PDT) From: Gary Winiger Message-Id: <200706211738.l5LHc5XM025039@marduk.eng.sun.com> To: John.Fischer@Sun.COM, PSARC-ext@sac.sfbay.sun.com Cc: Dermot.McCluskey@Sun.COM Subject: Re: IPSARC/2007/375 - Info directory file update service Status: RO Content-Length: 457 > This service will use the existing "Software Installation" > RBAC rights profile. What precisely does this mean? > 3. Interfaces > > Exported Interfaces > =================== > svc:/application/update/infodir:default Committed FRMI > application/info_dir_path Committed Property Is this intended to be administered? If so, what are the value and action (modify) authorizations. How does this service satisfy the SMF SAC policy? Gary.. From John.Fischer@Sun.COM Thu Jun 21 10:37:31 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5LHbVnh005461 for ; Thu, 21 Jun 2007 10:37:31 -0700 (PDT) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l5LHZqCT016857 for ; Thu, 21 Jun 2007 10:35:53 -0700 (PDT) Received: from fe-amer-03.sun.com ([192.18.108.177]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5LHZqwM001047 for ; Thu, 21 Jun 2007 17:35:52 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JJZ00B01Y3AJQ00@mail-amer.sun.com> (original mail from John.Fischer@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Thu, 21 Jun 2007 11:35:52 -0600 (MDT) Received: from 129.145.154.105 ([129.145.154.105]) by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JJZ00IZ1Y7QAVU8@mail-amer.sun.com> for PSARC-ext@sac.sfbay.sun.com; Thu, 21 Jun 2007 11:35:51 -0600 (MDT) Date: Thu, 21 Jun 2007 10:35:50 -0700 From: John Fischer Subject: PSARC/2007/375 - Info directory file update service Sender: John.Fischer@Sun.COM To: PSARC-ext@sac.sfbay.sun.com Cc: John Fischer , Dermot McCluskey Reply-to: John.Fischer@Sun.COM Message-id: <1182447350.52470.33.camel@sr1-umpk-55> MIME-version: 1.0 X-Mailer: Ximian Evolution 1.4.6.301c Content-type: multipart/mixed; boundary="Boundary_(ID_/JATMQZA66nWWiPFVFItiw)" Status: RO Content-Length: 2392 --Boundary_(ID_/JATMQZA66nWWiPFVFItiw) Content-type: text/plain Content-transfer-encoding: 7BIT PSARC, (corrected the subject line which had IPSARC instead of PSARC) I am sponsoring this project for Dermot McCluskey of the JDS group in Dublin Ireland. The case directory contains this proposal. I have set the timer for Thursday June 28th, 2007. This project is supplying a transient SMF service that rebuilds the Info doc directory files. The project is requesting a Patch release binding for Solaris. Thanks, John --Boundary_(ID_/JATMQZA66nWWiPFVFItiw) Content-type: text/plain; charset=ASCII; name=proposal.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=proposal.txt Info directory file update service 1. Summary This fast-track introduces the Info directory file update service, an SMF service which maintains directory files for Info documents. Patch release binding is requested. 2. Discussion GNU Manual files in the Info format are typically accompanied by a directory file which provides the user with a menu of the topics for which manuals are available. In the SFW consolidation, Info documents are located in /usr/sfw/share/info and /usr/share/info and each location includes its own directory file, called "dir", covering all the Info docs at that location. Currently, the directory files are generated at build-time using the "install-info" utility provided by texinfo(4). All the Info documents and the accompanying directory files for the consolidation are then delivered together (in SUNWsfinf). The problem is that we now wish to deliver the Info docs separately, as part of the relevant package. Also, other consolidations, such as JDS, may wish to install additional Info docs in the same locations and will therefore need to update the directory files. Install and remove Class Action Scripts that replicate the work of install-info would prove excessively complex and so a transient SMF service that rebuilds the directory file when any Info docs are installed, removed or modified is now proposed. This service will use the existing "Software Installation" RBAC rights profile. 3. Interfaces Exported Interfaces =================== svc:/application/update/infodir:default Committed FRMI application/info_dir_path Committed Property --Boundary_(ID_/JATMQZA66nWWiPFVFItiw)-- From sommerfeld@sun.com Thu Jun 21 10:47:18 2007 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5LHlHl3005809 for ; Thu, 21 Jun 2007 10:47:17 -0700 (PDT) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.14.0+Sun/8.14.0) with ESMTP id l5LHjV06001906; Thu, 21 Jun 2007 13:45:31 -0400 (EDT) Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.14.0+Sun/8.14.0/Submit) id l5LHjV14001905; Thu, 21 Jun 2007 13:45:31 -0400 (EDT) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: IPSARC/2007/375 - Info directory file update service From: Bill Sommerfeld To: John.Fischer@sun.com Cc: PSARC-ext@sac.sfbay.sun.com, Dermot McCluskey In-Reply-To: <1182446083.52470.8.camel@sr1-umpk-55> References: <1182446083.52470.8.camel@sr1-umpk-55> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 21 Jun 2007 13:45:30 -0400 Message-Id: <1182447930.1596.35.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1.1 Status: RO Content-Length: 833 Install and remove Class Action Scripts that replicate the work of install-info would prove excessively complex What, if anything, would prevent us from adding install-info to the miniroot? It doesn't appear to be large and unless I'm mistaken it doesn't seem to have significant dependencies. and so a transient SMF service that rebuilds the directory file when any Info docs are installed, removed or modified is now proposed. When is this service enabled/re-run? How does this interact with installs to alternate roots? (including live upgrade, zones, diskless, etc.). If I run this from the global zone to add an info package to a booted non-global zone, do I need to reboot the zone or otherwise reach into the zone to regenerate the info directory in that zone? - Bill From alan.coopersmith@sun.com Thu Jun 21 10:59:42 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5LHxfMt006449 for ; Thu, 21 Jun 2007 10:59:41 -0700 (PDT) Received: from [129.146.108.211] (almas.SFBay.Sun.COM [129.146.108.211]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5LHw1bB023092; Thu, 21 Jun 2007 10:58:02 -0700 (PDT) Message-ID: <467ABC29.7020309@sun.com> Date: Thu, 21 Jun 2007 10:58:01 -0700 From: Alan Coopersmith User-Agent: Thunderbird 2.0.0.0 (X11/20070423) MIME-Version: 1.0 To: Bill Sommerfeld CC: John.Fischer@sun.com, PSARC-ext@sac.sfbay.sun.com, Dermot McCluskey Subject: Re: IPSARC/2007/375 - Info directory file update service References: <1182446083.52470.8.camel@sr1-umpk-55> <1182447930.1596.35.camel@localhost> In-Reply-To: <1182447930.1596.35.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 576 Bill Sommerfeld wrote: > Install and remove Class Action Scripts that replicate > the work of install-info would prove excessively complex > > What, if anything, would prevent us from adding install-info to the > miniroot? It doesn't appear to be large and unless I'm mistaken it > doesn't seem to have significant dependencies. Putting it in the mini-root doesn't help those Live Upgrading from older releases that don't have it installed. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From casper@holland.sun.com Thu Jun 21 11:06:54 2007 Received: from dm-holland-01.uk.sun.com (dm-holland-01.UK.Sun.COM [129.156.101.192]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5LI6riY006705 for ; Thu, 21 Jun 2007 11:06:54 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [129.159.130.93]) by dm-holland-01.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5LI5EV9024517; Thu, 21 Jun 2007 19:05:14 +0100 (BST) Message-Id: <200706211805.l5LI5EV9024517@dm-holland-01.uk.sun.com> From: Casper.Dik@Sun.COM To: Alan Coopersmith cc: Bill Sommerfeld , John.Fischer@Sun.COM, PSARC-ext@sac.sfbay.sun.com, Dermot McCluskey Subject: Re: IPSARC/2007/375 - Info directory file update service In-Reply-To: <467ABC29.7020309@sun.com> References: <1182446083.52470.8.camel@sr1-umpk-55> <1182447930.1596.35.camel@localhost> <467ABC29.7020309@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 Jun 2007 20:05:14 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 828 >Bill Sommerfeld wrote: >> Install and remove Class Action Scripts that replicate >> the work of install-info would prove excessively complex >> >> What, if anything, would prevent us from adding install-info to the >> miniroot? It doesn't appear to be large and unless I'm mistaken it >> doesn't seem to have significant dependencies. > >Putting it in the mini-root doesn't help those Live Upgrading from >older releases that don't have it installed. And again we get to a point that *any* improvements we make to our tools to help install cannot be used until two or more releases have passed. (update_drv -b, useradd's proposed "-R/-b" options, install-info) It's time to step back and try to resolve this issue; we don't even have the tools to check whether our packages abide by the rules. Casper From bart.smaalders@Sun.COM Thu Jun 21 11:13:27 2007 Received: from zion.eng.sun.com (zion [129.146.17.75]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5LIDRAe006926 for ; Thu, 21 Jun 2007 11:13:27 -0700 (PDT) Received: from [129.146.228.109] (cyber [129.146.228.109]) by zion.eng.sun.com (8.13.7+Sun/8.13.7) with ESMTP id l5LIBmLJ014348; Thu, 21 Jun 2007 11:11:49 -0700 (PDT) Message-ID: <467ABEED.1020203@Sun.COM> Date: Thu, 21 Jun 2007 11:09:49 -0700 From: Bart Smaalders Organization: Sun Microsystems User-Agent: Thunderbird 2.0.0.0 (X11/20070423) MIME-Version: 1.0 To: Casper.Dik@sun.com CC: Alan Coopersmith , Bill Sommerfeld , John.Fischer@sun.com, PSARC-ext@sac.sfbay.sun.com, Dermot McCluskey Subject: Re: IPSARC/2007/375 - Info directory file update service References: <1182446083.52470.8.camel@sr1-umpk-55> <1182447930.1596.35.camel@localhost> <467ABC29.7020309@sun.com> <200706211805.l5LI5EV9024517@dm-holland-01.uk.sun.com> In-Reply-To: <200706211805.l5LI5EV9024517@dm-holland-01.uk.sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1350 Casper.Dik@sun.com wrote: >> Bill Sommerfeld wrote: >>> Install and remove Class Action Scripts that replicate >>> the work of install-info would prove excessively complex >>> >>> What, if anything, would prevent us from adding install-info to the >>> miniroot? It doesn't appear to be large and unless I'm mistaken it >>> doesn't seem to have significant dependencies. >> Putting it in the mini-root doesn't help those Live Upgrading from >> older releases that don't have it installed. > > > And again we get to a point that *any* improvements we make to our tools > to help install cannot be used until two or more releases have passed. > > (update_drv -b, useradd's proposed "-R/-b" options, install-info) > > > It's time to step back and try to resolve this issue; we don't even have > the tools to check whether our packages abide by the rules. > > Casper > This is another reasonwhy installation/packaging needs to be about laying files down on the system, not running arbitrary actions in packaging install context. Note also that a unified packaging/patching model could also help cope with this; installation of newer packages could require minimum levels of the packaging tools for their application. - Bart -- Bart Smaalders Solaris Kernel Performance barts@cyber.eng.sun.com http://blogs.sun.com/barts From Michael.Hunter@Sun.COM Thu Jun 21 12:11:18 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5LJBI4i009404 for ; Thu, 21 Jun 2007 12:11:18 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5LJ9db0008927 for ; Thu, 21 Jun 2007 12:09:39 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l5LJ9YV0013531 for ; Thu, 21 Jun 2007 12:09:34 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JK0007012DP7W00@fe-sfbay-10.sun.com> (original mail from Michael.Hunter@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Thu, 21 Jun 2007 12:09:34 -0700 (PDT) Received: from sun.com ([10.7.251.174]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JK000B102JYKFA0@fe-sfbay-10.sun.com> for PSARC-ext@sac.sfbay.sun.com; Thu, 21 Jun 2007 12:09:34 -0700 (PDT) Date: Thu, 21 Jun 2007 12:09:33 -0700 From: Michael Hunter Subject: Re: PSARC/2007/375 - Info directory file update service In-reply-to: <1182447350.52470.33.camel@sr1-umpk-55> Sender: Michael.Hunter@Sun.COM To: John.Fischer@Sun.COM Cc: PSARC-ext@sac.sfbay.sun.com, Dermot McCluskey Message-id: <20070621120933.000049ea@localhost> Organization: SMI MIME-version: 1.0 X-Mailer: Claws Mail 2.9.2-csw (GTK+ 2.10.11; i386-pc-solaris2.8) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT References: <1182447350.52470.33.camel@sr1-umpk-55> Status: RO Content-Length: 635 On Thu, 21 Jun 2007 10:35:50 -0700 John Fischer wrote: [...] svc:/application/update/infodir:default Committed FRMI application/info_dir_path Committed Property As best I can tell if there is a structure or taxonomy for service names its not well followed. But I don't see many examples of type/action/object:default. inetd-upgrade which is somewhat analogous flattens that out. I think its worthwhile to think ahead to something which rebuilt preformatted man pages and windex databases and figure out if the two should share some structure even if just in service name and common properties. mph From Nicolas.Williams@sun.com Thu Jun 21 12:21:11 2007 Received: from localhost.Central.Sun.COM (dhcp-uaus08-128-213.Central.Sun.COM [129.153.128.213]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5LJLAvr009916 for ; Thu, 21 Jun 2007 12:21:10 -0700 (PDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l5LJIYHm029395; Thu, 21 Jun 2007 14:18:34 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l5LJIYp3029394; Thu, 21 Jun 2007 14:18:34 -0500 (CDT) X-Authentication-Warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Thu, 21 Jun 2007 14:18:32 -0500 From: Nicolas Williams To: Michael Hunter Cc: John.Fischer@sun.com, PSARC-ext@sac.sfbay.sun.com, Dermot McCluskey Subject: Re: PSARC/2007/375 - Info directory file update service Message-ID: <20070621191831.GU28070@Sun.COM> References: <1182447350.52470.33.camel@sr1-umpk-55> <20070621120933.000049ea@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070621120933.000049ea@localhost> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 749 On Thu, Jun 21, 2007 at 12:09:33PM -0700, Michael Hunter wrote: > I think its worthwhile to think ahead to something which rebuilt > preformatted man pages and windex databases and figure out if the two > should share some structure even if just in service name and common > properties. I was thinking the same thing. Having at least pre-built catman indexes would help Solaris be much more user-friendly. Having two services for much the same sort of thing (one for catman, one for GNU info) seems silly; one service with a generic name such as, say, svc:/system/docs, seems more appropriate. (If catman(1M) had had a -R option then we could just have a class action script for man pages that updates the index on pkg/patch install.) Nico -- From boyd.adamson@gmail.com Thu Jun 21 18:26:37 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5M1Qb3m023142 for ; Thu, 21 Jun 2007 18:26:37 -0700 (PDT) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5M1OwjY024541 for ; Thu, 21 Jun 2007 18:24:58 -0700 (PDT) Received: from relay41i.sun.com ([192.5.209.70]) by brmea-mail-4.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5M1Ovc9011271 for ; Fri, 22 Jun 2007 01:24:57 GMT Received: from mms48es.sun.com ([160.41.221.231] [160.41.221.231]) by relay41i.sun.com with ESMTP id BT-MMP-36868 for PSARC-ext@sac.sfbay.sun.com; Fri, 22 Jun 2007 01:24:57 Z Received: from relay42i.sun.com ([192.5.209.72] [192.5.209.72]) by mms48es.sun.com with ESMTP id BT-MMP-243607 for PSARC-ext@sac.sfbay.sun.com; Fri, 22 Jun 2007 01:24:57 Z Received: from nz-out-0506.google.com ([64.233.162.224] [64.233.162.224]) by relay4i.sun.com with ESMTP id BT-MMP-4638141 for PSARC-ext@sac.sfbay.sun.com; Fri, 22 Jun 2007 01:24:57 Z Received: by nz-out-0506.google.com with SMTP id s18so692999nze for ; Thu, 21 Jun 2007 18:24:56 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=CzJkCxKkFDiPe9PkuPyxWo4BS28gxqYZvkbPo3lLwbGytb5VJ1CZsbYs1Xqia65ZUWMFlpVGnACKwAFohBPzy+i3PN73dx6KgFSc0d4hbizodw+f4IQQQU4g4oQfmm+jRuLL33kFJ3yNMvU4pzIqd114C/0iD933eJGnaUyQUu8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:references:x-google-sender-auth; b=jUe/dJC2OHL/NCn48w5lQwo7pjx2WbA5TLbuGYSbVk/NHPug1/lUyT+SE/qJh13RcQ7jP1q1aiHv3A+KcY27zELwn6Ivdsw30DxRIqVnH0rWB+IdQ75bNFO+LiYyUvr9fTmnAd5sxBZlkIUAiNGA/SzF3y087KZuRIKTTnt4G2o= Received: by 10.114.174.2 with SMTP id w2mr2337694wae.1182475496349; Thu, 21 Jun 2007 18:24:56 -0700 (PDT) Received: by 10.114.235.18 with HTTP; Thu, 21 Jun 2007 18:24:56 -0700 (PDT) Message-Id: <2d0f097e0706211824o1ab635beq7493446b83453b5@mail.gmail.com> Date: Fri, 22 Jun 2007 11:24:56 +1000 From: "Boyd Adamson" Sender: boyd.adamson@gmail.com To: "Nicolas Williams" Subject: Re: PSARC/2007/375 - Info directory file update service Cc: "Michael Hunter" , John.Fischer@sun.com, "Dermot McCluskey" , PSARC-ext@sac.sfbay.sun.com In-Reply-To: <20070621191831.GU28070@Sun.COM> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_152088_10872059.1182475496321" References: <1182447350.52470.33.camel@sr1-umpk-55> <20070621120933.000049ea@localhost> <20070621191831.GU28070@Sun.COM> X-Google-Sender-Auth: 7ed461f312d9396a Status: RO Content-Length: 2885 ------=_Part_152088_10872059.1182475496321 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 6/22/07, Nicolas Williams wrote: > > On Thu, Jun 21, 2007 at 12:09:33PM -0700, Michael Hunter wrote: > > I think its worthwhile to think ahead to something which rebuilt > > preformatted man pages and windex databases and figure out if the two > > should share some structure even if just in service name and common > > properties. > > I was thinking the same thing. Having at least pre-built catman indexes > would help Solaris be much more user-friendly. > > Having two services for much the same sort of thing (one for catman, one > for GNU info) seems silly; one service with a generic name such as, say, > svc:/system/docs, seems more appropriate. > I disagree. What happens if there is later some new docs method (Docbook source, for example) that needs a new indexing/formatting process? What happens if someone wants to make an html collection and update that with SMF? It seems to me that the logical thing to do would be to have a category (say, svc:/application/docs) that all those services go under and then a milestone that can depend on all of them. Boyd ------=_Part_152088_10872059.1182475496321 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline
On 6/22/07, Nicolas Williams <Nicolas.Williams@sun.com> wrote:
On Thu, Jun 21, 2007 at 12:09:33PM -0700, Michael Hunter wrote:
> I think its worthwhile to think ahead to something which rebuilt
> preformatted man pages and windex databases and figure out if the two
> should share some structure even if just in service name and common
> properties.

I was thinking the same thing.  Having at least pre-built catman indexes
would help Solaris be much more user-friendly.

Having two services for much the same sort of thing (one for catman, one
for GNU info) seems silly; one service with a generic name such as, say,
svc:/system/docs, seems more appropriate.

I disagree. What happens if there is later some new docs method (Docbook source, for example) that needs a new indexing/formatting process? What happens if someone wants to make an html collection and update that with SMF?

It seems to me that the logical thing to do would be to have a category (say, svc:/application/docs) that all those services go under and then a milestone that can depend on all of them.

Boyd

------=_Part_152088_10872059.1182475496321-- From gww@eng.sun.com Fri Jun 22 12:22:27 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5MJMRF5008723 for ; Fri, 22 Jun 2007 12:22:27 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5MJKk4A018950; Fri, 22 Jun 2007 12:20:47 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5MJNaw5026411; Fri, 22 Jun 2007 12:23:36 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5MJNZqh026410; Fri, 22 Jun 2007 12:23:35 -0700 (PDT) Date: Fri, 22 Jun 2007 12:23:35 -0700 (PDT) From: Gary Winiger Message-Id: <200706221923.l5MJNZqh026410@marduk.eng.sun.com> To: gww@eng.sun.com, Dermot.McCluskey@Sun.COM Subject: Re: IPSARC/2007/375 - Info directory file update service Cc: John.Fischer@Sun.COM, PSARC-ext@sac.sfbay.sun.com X-Sun-Charset: US-ASCII Status: RO Content-Length: 1247 > >> This service will use the existing "Software Installation" > >> RBAC rights profile. > >> > >> > > > > What precisely does this mean? > > > > > > That no new RBAC profiles are being defined by this case. OK, so then what does "will use" mean? Is it delivering something into Software Installation? Is it consuming something out of Software Installation? If either, it is appropriate to state what. > >> svc:/application/update/infodir:default Committed FRMI > >> application/info_dir_path Committed Property > >> > >> > > > > Is this intended to be administered? If so, what are the > > value and action (modify) authorizations. > > "Service Management". I don't understand the answer: o Is the service and its property intended to be administered? o What action/value_authorization is defined for this service? o Is there a modify_authorization defined for this service? If so what is it? If not, perhaps one is needed. > > How does this service satisfy the SMF SAC policy? > Can you point me to that document? It's in the usual place: http://opensolaris.org/os/community/arc/policies/SMF-policy/ Or if you'd rather access the same internal to Sun: http://sac.eng/cgi-bin/bp.cgi?NAME=SMF.bp Gary.. From Garrett.Damore@Sun.COM Fri Jun 22 13:16:03 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5MKG3iN009920 for ; Fri, 22 Jun 2007 13:16:03 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5MKEOLM029301 for ; Fri, 22 Jun 2007 13:14:24 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l5MKEJfB016096 for ; Fri, 22 Jun 2007 13:14:19 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JK200C0102AAX00@fe-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Fri, 22 Jun 2007 13:14:19 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JK200C8E07UX810@fe-sfbay-10.sun.com>; Fri, 22 Jun 2007 13:14:19 -0700 (PDT) Date: Fri, 22 Jun 2007 13:12:00 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2007/375 - Info directory file update service In-reply-to: <200706221640.l5MGeB9T018669@dm-holland-02.uk.sun.com> Sender: Garrett.Damore@Sun.COM To: Casper.Dik@Sun.COM Cc: Nicolas Williams , Stephen Hahn , Michael Hunter , John.Fischer@Sun.COM, Dermot McCluskey , PSARC-ext@sac.sfbay.sun.com Message-id: <467C2D10.2020203@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1182447350.52470.33.camel@sr1-umpk-55> <20070621120933.000049ea@localhost> <20070622155120.GB17730@eng.sun.com> <467BF1DD.9050407@sun.com> <20070622160630.GN28070@Sun.COM> <467BF5C7.9050008@sun.com> <200706221640.l5MGeB9T018669@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 2112 Casper.Dik@Sun.COM wrote: >> Nicolas Williams wrote: >> >>> On Fri, Jun 22, 2007 at 08:59:25AM -0700, Garrett D'Amore wrote: >>> >>> >>>> We've not delivered catman hierarchies for some time. I think that >>>> processor speeds have reached the point where catman pages no longer >>>> make sense. I'd like to see support for them EOF'd at some point in the >>>> future. >>>> >>>> >>> I agree, but I'm not sure there's any value in EOFing catmans. >>> >>> >> Removal of dead/useless code is always a good thing. It results in less >> code to maintain, makes the remaining code easier to understand, and >> allows for smaller binaries. >> >> It also helps with the build times. ;-) >> > > Not until the largest manual page can be formatted on the slowest supported > CPU in under .1 of a second. > Hmm... most of the man pages I tested on my AMD64 system (bottom-of-the-end 1.8GHz U20) formatted in less than .1 second. The extreme counterexamples I could find were the tcsh and bash man pages. These took .2 seconds. That was just enough time for me to notice that it was not quite instantaneous, but plenty fast enough for any real system. Now on a 500MHz US-IIe system, it was slightly different. It took approximately .9 seconds of CPU time to format the man page. (It was almost 4 seconds to present, thanks to waiting on disk.) tcsh(1) is an extreme example... 92 pages, as is bash(1) at 104 pages. A more typical example, libpopt(3) , at 19 pages, takes only .5 seconds to deliver on this aging 500MHz CPU. > I use catman and I *hate* it when it takes time to format the manual pages. > I wonder if maybe someone should spring to buy you a faster system... that 300MHz Ultra 30 you're running on is probably due for an upgrade. :-) > Yes, I know that "nroff" is faster than getting at the manual page over > the web, but that's because the web is *slow* and *cumbersome* when it > comes to presenting text. > I won't disagree with you there. But the web wasn't germane to this conversation. -- Garrett > Casper > From Darren.Reed@Sun.COM Sat Jun 23 00:25:31 2007 Received: from sineb-mail-2.sun.com ([192.18.19.7]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5N7PUXD026808 for ; Sat, 23 Jun 2007 00:25:31 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5N7Nj4D008947 for ; Sat, 23 Jun 2007 07:23:45 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JK200B01UYFYH00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Sat, 23 Jun 2007 15:23:45 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JK2000RGV7J8INV@mail-apac.sun.com>; Sat, 23 Jun 2007 15:23:45 +0800 (SGT) Date: Sat, 23 Jun 2007 00:23:42 -0700 From: Darren.Reed@Sun.COM Subject: Re: PSARC/2007/375 - Info directory file update service In-reply-to: <20070622105207.0000295f@localhost> Sender: Darren.Reed@Sun.COM To: Michael Hunter Cc: Nicolas Williams , "Garrett D'Amore" , John.Fischer@Sun.COM, Stephen Hahn , Dermot McCluskey , PSARC-ext@sac.sfbay.sun.com Message-id: <467CCA7E.1020609@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1182447350.52470.33.camel@sr1-umpk-55> <20070621120933.000049ea@localhost> <20070622155120.GB17730@eng.sun.com> <467BF1DD.9050407@sun.com> <20070622160630.GN28070@Sun.COM> <467BF5C7.9050008@sun.com> <20070622162928.GQ28070@Sun.COM> <20070622105207.0000295f@localhost> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 2861 This appears to be peripherally related to the case but... Michael Hunter wrote: >On Fri, 22 Jun 2007 11:29:29 -0500 >Nicolas Williams wrote: > > >>On Fri, Jun 22, 2007 at 09:16:07AM -0700, Garrett D'Amore wrote: >> >>>Nicolas Williams wrote: >>> >>>>Why a cronjob? If a pkgadd is done without -R then the pkg's man class >>>>action script (or postinstall) should restart the index service (else >>>>the index will be re-generated on boot). >>>> >>>> >>>That would work. But it will be a release or two before all packaging >>>scripts can rely on the service. The cronjob gets over the hump. It >>>also copes with software that was not installed via pkgadd... such as >>>when someone does "make install" on some other FOSS. :-) >>> >>The pkg scripts can use SMF when: a) the pkg is for S10 or higher AND b) >>the pkg is being installed on the running system. The pkg scripts >>cannot use features from S9 and up when the pkg is being added or >>removed with -R. >> > >I don't want this done on a series of pkgadd's until the end. Having >the user need to remember to use 'svcadm disable' and 'svcadm enable' >to bracket these lacks usability. > If catman could work with individual man pages and not just scan entire sections, this would be less onerous... >>The use of a cronjob for this feels... icky. I'd rather have a >>non-transient service using a user-land FEM interface to auto-detect >>changes to mandirs and re-gen the index some suitable time after the >>last change. >> > >Cron doesn't feel completely disgusting to me. > But users shouldn't have to wait some "random" amount of time after the package is installed to see the man pages in the index. And there's no guarantee that the cron job will trigger off at the right time, either, except that eventually all should be well. >Some FEM agent agent >with a bit of memory is better but still still somewhat arbitrary. But >if the user wants they should be able to restart one of the update >serices that Stephen mentioned and get the right results. Being able to >'pkg-update --just-do-it upgrade' ; svcadm restart upgrade/docs' or the >equivalent and not have to know which one(s) you need to hit would be >wonderful. > I'd like to see an FEM agent that monitored the directories and tickled a restart of the service when it gets an indication that there have been changes to the installed man pages, doing away with the need for any manual interaction/reboot. Seperate to this case but related to the problem being discussed here, catman should be able to be given individual pages to add to the index for a section, rather than needing to scan/rebuild an entire section, allowing for much better/quicker incremental building of the index as new man pages are installed/updated. Darren (someone who hates having to remember to do "catman -w") From Darren.Reed@Sun.COM Sat Jun 23 00:32:40 2007 Received: from sineb-mail-1.sun.com ([192.18.19.6]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5N7WdIi027277 for ; Sat, 23 Jun 2007 00:32:40 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5N7Usop013355 for ; Sat, 23 Jun 2007 07:30:54 GMT Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JK200901V5HNN00@mail-apac.sun.com> (original mail from Darren.Reed@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Sat, 23 Jun 2007 15:30:54 +0800 (SGT) Received: from [129.146.106.55] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JK200FMEVJGWQMQ@mail-apac.sun.com>; Sat, 23 Jun 2007 15:30:54 +0800 (SGT) Date: Sat, 23 Jun 2007 00:30:52 -0700 From: Darren.Reed@Sun.COM Subject: Re: IPSARC/2007/375 - Info directory file update service In-reply-to: <467BD306.1090807@Sun.COM> Sender: Darren.Reed@Sun.COM To: Dermot.McCluskey@Sun.COM Cc: Bill Sommerfeld , John.Fischer@Sun.COM, PSARC-ext@sac.sfbay.sun.com Message-id: <467CCC2C.3000408@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1182446083.52470.8.camel@sr1-umpk-55> <1182447930.1596.35.camel@localhost> <467BD306.1090807@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20060120 Status: RO Content-Length: 799 Dermot.McCluskey@Sun.COM wrote: > [resending due to bounced mail on first attempt.] > > Bill Sommerfeld wrote: > >> When is this service enabled/re-run? How does this interact with >> installs to alternate roots? (including live upgrade, zones, diskless, >> etc.). >> >> If I run this from the global zone to add an info package to a booted >> non-global zone, do I need to reboot the zone or otherwise reach into >> the zone to regenerate the info directory in that zone? >> >> > > It's run on reboot. > > Yes - you would need to wait for the next reboot of the non-global > zone to see it take effect. I don't know about you, but to me this seems to be a major problem. Nothing should have to rebooted in order for documentation to be updated after new files have been installed. Darren From casper@holland.sun.com Sat Jun 23 01:27:20 2007 Received: from dm-holland-02.uk.sun.com (dm-holland-02.UK.Sun.COM [129.156.101.225]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5N8RJCa028269 for ; Sat, 23 Jun 2007 01:27:19 -0700 (PDT) Received: from holland (room101.Holland.Sun.COM [129.159.130.93]) by dm-holland-02.uk.sun.com (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5N8Pbh4016702; Sat, 23 Jun 2007 09:25:37 +0100 (BST) Message-Id: <200706230825.l5N8Pbh4016702@dm-holland-02.uk.sun.com> From: Casper.Dik@Sun.COM To: Darren.Reed@Sun.COM cc: Michael Hunter , Nicolas Williams , "Garrett D'Amore" , John.Fischer@Sun.COM, Stephen Hahn , Dermot McCluskey , PSARC-ext@sac.sfbay.sun.com Subject: Re: PSARC/2007/375 - Info directory file update service In-Reply-To: <467CCA7E.1020609@Sun.COM> References: <1182447350.52470.33.camel@sr1-umpk-55> <20070621120933.000049ea@localhost> <20070622155120.GB17730@eng.sun.com> <467BF1DD.9050407@sun.com> <20070622160630.GN28070@Sun.COM> <467BF5C7.9050008@sun.com> <20070622162928.GQ28070@Sun.COM> <20070622105207.0000295f@localhost> <467CCA7E.1020609@Sun.COM> Date: Sat, 23 Jun 2007 10:25:36 +0200 Sender: casper@holland.sun.com Status: RO Content-Length: 783 >But users shouldn't have to wait some "random" amount of time >after the package is installed to see the man pages in the index. >And there's no guarantee that the cron job will trigger off at >the right time, either, except that eventually all should be well. It's how others do it, though; and the manual pages are there and available immediately; it's just that the quick index will not be there. >I'd like to see an FEM agent that monitored the directories and >tickled a restart of the service when it gets an indication that >there have been changes to the installed man pages, doing away >with the need for any manual interaction/reboot. I very much dislike the idea of a FEM agent which sits there to generate what is basically static content. It's just bloat. Casper From Garrett.Damore@Sun.COM Sat Jun 23 12:29:38 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5NJTcrW006641 for ; Sat, 23 Jun 2007 12:29:38 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5NJRvT4013607 for ; Sat, 23 Jun 2007 12:27:57 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l5NJRq3p006425 for ; Sat, 23 Jun 2007 12:27:52 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JK300K01SKGB700@fe-sfbay-10.sun.com> (original mail from Garrett.Damore@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Sat, 23 Jun 2007 12:27:52 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JK300H7BSQFLVC0@fe-sfbay-10.sun.com>; Sat, 23 Jun 2007 12:27:52 -0700 (PDT) Date: Sat, 23 Jun 2007 12:25:31 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2007/375 - Info directory file update service In-reply-to: <200706230825.l5N8Pbh4016702@dm-holland-02.uk.sun.com> Sender: Garrett.Damore@Sun.COM To: Casper.Dik@Sun.COM Cc: Darren.Reed@Sun.COM, Michael Hunter , Nicolas Williams , John.Fischer@Sun.COM, Stephen Hahn , Dermot McCluskey , PSARC-ext@sac.sfbay.sun.com Message-id: <467D73AB.3060807@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1182447350.52470.33.camel@sr1-umpk-55> <20070621120933.000049ea@localhost> <20070622155120.GB17730@eng.sun.com> <467BF1DD.9050407@sun.com> <20070622160630.GN28070@Sun.COM> <467BF5C7.9050008@sun.com> <20070622162928.GQ28070@Sun.COM> <20070622105207.0000295f@localhost> <467CCA7E.1020609@Sun.COM> <200706230825.l5N8Pbh4016702@dm-holland-02.uk.sun.com> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1374 Casper.Dik@Sun.COM wrote: >> But users shouldn't have to wait some "random" amount of time >> after the package is installed to see the man pages in the index. >> And there's no guarantee that the cron job will trigger off at >> the right time, either, except that eventually all should be well. >> > > It's how others do it, though; and the manual pages are there and > available immediately; it's just that the quick index will not > be there. > Here's a wild thought. Why not have *man* trigger the rebuild on a windex if it finds the index file is out of date? Then its not something that is just sitting around. The other idea is that it could be kicked off from installation scripts.... I like that. Or even better yet, instead of using installf, use installman or some new wrapper around installf that does the necessary additions to the windex file at installation time ... without a full rebuild. > >> I'd like to see an FEM agent that monitored the directories and >> tickled a restart of the service when it gets an indication that >> there have been changes to the installed man pages, doing away >> with the need for any manual interaction/reboot. >> > > I very much dislike the idea of a FEM agent which sits there to > generate what is basically static content. It's just bloat. > Yeah, me too. -- Garrett > > Casper > From boyd-adamson@usa.net Sun Jun 24 18:46:11 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5P1kBUO029964 for ; Sun, 24 Jun 2007 18:46:11 -0700 (PDT) Received: from sca-ea-mail-1.sun.com (sca-ea-mail-1.Sun.COM [192.18.43.24]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5P1iUP0000172 for ; Sun, 24 Jun 2007 18:44:30 -0700 (PDT) Received: from relay24.sun.com (ip192-12-251-74.block6.us.syntegra.com [192.12.251.74]) by sca-ea-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l5P1iQ7m017528 for ; Mon, 25 Jun 2007 01:44:30 GMT Received: from mms24es.sun.com ([150.143.232.74] [150.143.232.74]) by relay24.sun.com with ESMTP id BT-MMP-390755 for PSARC-ext@sac.sfbay.sun.com; Mon, 25 Jun 2007 01:44:26 Z Received: from mms23bas.mms.us.syntegra.com (mms23bas.mms.us.syntegra.com [192.12.251.50]) by mms24es.sun.com with ESMTP id BT-MMP-1938359 for PSARC-ext@sac.sfbay.sun.com; Mon, 25 Jun 2007 01:44:25 Z Received: from ipmail03.adl2.internode.on.net ([203.16.214.135] [203.16.214.135]) by relay23.sun.com with ESMTP id BT-MMP-3573921 for PSARC-ext@sac.sfbay.sun.com; Mon, 25 Jun 2007 01:44:24 Z X-IronPort-AV: E=Sophos;i="4.16,457,1175437800"; d="scan'208";a="107169584" Received: from ppp157-138.static.internode.on.net (HELO whirlpool) ([150.101.157.138]) by ipmail03.adl2.internode.on.net with ESMTP; 25 Jun 2007 11:14:18 +0930 Received: from eddy.tactio.lan ([10.11.12.2] helo=[127.0.0.1] ident=brontitall) by whirlpool with esmtp (Exim 3.36 #1 (Debian)) id 1I2dco-0007d3-00; Mon, 25 Jun 2007 11:44:18 +1000 In-Reply-To: <200706230825.l5N8Pbh4016702@dm-holland-02.uk.sun.com> References: <1182447350.52470.33.camel@sr1-umpk-55> <20070621120933.000049ea@localhost> <20070622155120.GB17730@eng.sun.com> <467BF1DD.9050407@sun.com> <20070622160630.GN28070@Sun.COM> <467BF5C7.9050008@sun.com> <20070622162928.GQ28070@Sun.COM> <20070622105207.0000295f@localhost> <467CCA7E.1020609@Sun.COM> <200706230825.l5N8Pbh4016702@dm-holland-02.uk.sun.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9F31E43B-F535-45E8-AFF4-65811358D4EB@usa.net> Cc: Darren.Reed@Sun.COM, John.Fischer@Sun.COM, Nicolas Williams , Michael Hunter , "Garrett D'Amore" , Dermot McCluskey , Stephen Hahn , PSARC-ext@sac.sfbay.sun.com Content-Transfer-Encoding: 7bit From: Boyd Adamson Subject: Re: PSARC/2007/375 - Info directory file update service Date: Mon, 25 Jun 2007 11:44:35 +1000 To: Casper.Dik@Sun.COM X-Mailer: Apple Mail (2.752.3) Status: RO Content-Length: 1325 On 23/06/2007, at 6:25 PM, Casper.Dik@Sun.COM wrote: >> But users shouldn't have to wait some "random" amount of time >> after the package is installed to see the man pages in the index. >> And there's no guarantee that the cron job will trigger off at >> the right time, either, except that eventually all should be well. > > It's how others do it, though; and the manual pages are there and > available immediately; it's just that the quick index will not > be there. > >> I'd like to see an FEM agent that monitored the directories and >> tickled a restart of the service when it gets an indication that >> there have been changes to the installed man pages, doing away >> with the need for any manual interaction/reboot. > > I very much dislike the idea of a FEM agent which sits there to > generate what is basically static content. It's just bloat. On the other hand, a single system-wide FEM monitor that serves SMF may well be a nice thing. If there were some way for a service to register files and/or directories that it's interested in (presumably a property) and then have its refresh method called on change that may be more generally applicable. On the other hand it would probably have to have some kind of pause functionality so that it doesn't run after 1 of 100 man pages are installed. Boyd From Nicolas.Williams@sun.com Mon Jun 25 08:18:33 2007 Received: from localhost.Central.Sun.COM (dhcp-uaus08-128-213.Central.Sun.COM [129.153.128.213]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5PFIX0B013308 for ; Mon, 25 Jun 2007 08:18:33 -0700 (PDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l5PFFpbW003774; Mon, 25 Jun 2007 10:15:51 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l5PFFpSr003773; Mon, 25 Jun 2007 10:15:51 -0500 (CDT) X-Authentication-Warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 25 Jun 2007 10:15:51 -0500 From: Nicolas Williams To: Boyd Adamson Cc: Casper.Dik@sun.com, Darren.Reed@sun.com, John.Fischer@sun.com, Michael Hunter , "Garrett D'Amore" , Dermot McCluskey , Stephen Hahn , PSARC-ext@sac.sfbay.sun.com Subject: Re: PSARC/2007/375 - Info directory file update service Message-ID: <20070625151550.GH28070@Sun.COM> References: <1182447350.52470.33.camel@sr1-umpk-55> <20070621120933.000049ea@localhost> <20070622155120.GB17730@eng.sun.com> <467BF1DD.9050407@sun.com> <20070622160630.GN28070@Sun.COM> <467BF5C7.9050008@sun.com> <20070622162928.GQ28070@Sun.COM> <20070622105207.0000295f@localhost> <467CCA7E.1020609@Sun.COM> <200706230825.l5N8Pbh4016702@dm-holland-02.uk.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9F31E43B-F535-45E8-AFF4-65811358D4EB@usa.net> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 588 Casper> I very much dislike the idea of a FEM agent which sits there to Casper> generate what is basically static content. It's just bloat. As Boyd points out, it could be svc.startd itself. The consensus on file depencencies is/was that there's no reliable way for a FEM agent to know when someone is done editing some file's or drectory's contents, which makes file deps less than ideal, but here is a case where a cronjob (one of the alternatives discussed) is no better. Implementing file deps via FEM in svc.startd + dampening may be a decent solution for this class of problems. From Nicolas.Williams@sun.com Mon Jun 25 08:23:15 2007 Received: from localhost.Central.Sun.COM (dhcp-uaus08-128-213.Central.Sun.COM [129.153.128.213]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5PFNE6A013407 for ; Mon, 25 Jun 2007 08:23:14 -0700 (PDT) Received: from localhost.Central.Sun.COM (localhost [127.0.0.1]) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1) with ESMTP id l5PFKXkk003785; Mon, 25 Jun 2007 10:20:33 -0500 (CDT) Received: (from nw141292@localhost) by localhost.Central.Sun.COM (8.14.1+Sun/8.14.1/Submit) id l5PFKXBZ003784; Mon, 25 Jun 2007 10:20:33 -0500 (CDT) X-Authentication-Warning: localhost.Central.Sun.COM: nw141292 set sender to Nicolas.Williams@sun.com using -f Date: Mon, 25 Jun 2007 10:20:33 -0500 From: Nicolas Williams To: "Garrett D'Amore" Cc: Casper.Dik@sun.com, Darren.Reed@sun.com, Michael Hunter , John.Fischer@sun.com, Stephen Hahn , Dermot McCluskey , PSARC-ext@sac.sfbay.sun.com Subject: Re: PSARC/2007/375 - Info directory file update service Message-ID: <20070625152032.GI28070@Sun.COM> References: <20070621120933.000049ea@localhost> <20070622155120.GB17730@eng.sun.com> <467BF1DD.9050407@sun.com> <20070622160630.GN28070@Sun.COM> <467BF5C7.9050008@sun.com> <20070622162928.GQ28070@Sun.COM> <20070622105207.0000295f@localhost> <467CCA7E.1020609@Sun.COM> <200706230825.l5N8Pbh4016702@dm-holland-02.uk.sun.com> <467D73AB.3060807@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <467D73AB.3060807@sun.com> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1108 [To what list to send these design discussions? psarc-ext seems inappropriate.] On Sat, Jun 23, 2007 at 12:25:31PM -0700, Garrett D'Amore wrote: > Here's a wild thought. Why not have *man* trigger the rebuild on a > windex if it finds the index file is out of date? Then its not > something that is just sitting around. How can it know? Sure, if it stumbles on a manpage that is newer than the windex then it knows, but if I never find that newer man page because I can't find it with man -k... > The other idea is that it could be kicked off from installation > scripts.... I like that. Or even better yet, instead of using installf, > use installman or some new wrapper around installf that does the > necessary additions to the windex file at installation time ... without > a full rebuild. This could work, I think: make installf or pkgadd smart about mandirs or infodirs, or what have you, and, when installed on a running system, do the right thing. But also, it should be possible to do this with class action scripts and postinstall scripts (if [ -z "$PKG_INSTALL_ROOT" ]; then ...). From Dermot.McCluskey@Sun.COM Mon Jun 25 08:53:07 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5PFr7bT014180 for ; Mon, 25 Jun 2007 08:53:07 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-2.UK.Sun.COM [129.156.42.6]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l5PFpPU3028072 for ; Mon, 25 Jun 2007 08:51:25 -0700 (PDT) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5PFpJJV007124 for ; Mon, 25 Jun 2007 15:51:19 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JK7002017X5E500@d1-emea-09.sun.com> (original mail from Dermot.McCluskey@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Mon, 25 Jun 2007 16:51:19 +0100 (BST) Received: from [129.156.220.17] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JK7003QY81IB2D2@d1-emea-09.sun.com> for PSARC-ext@sac.sfbay.sun.com; Mon, 25 Jun 2007 16:51:19 +0100 (BST) Date: Mon, 25 Jun 2007 16:51:18 +0100 From: Dermot.McCluskey@Sun.COM Subject: Re: IPSARC/2007/375 - Info directory file update service In-reply-to: <20070622174814.GR28070@Sun.COM> Sender: Dermot.McCluskey@Sun.COM To: Nicolas Williams Cc: James Carlson , John.Fischer@Sun.COM, PSARC-ext@sac.sfbay.sun.com Message-id: <467FE476.5040606@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <1182446083.52470.8.camel@sr1-umpk-55> <18042.46293.964044.369931@gargle.gargle.HOWL> <467BA838.2060202@Sun.COM> <20070622174814.GR28070@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20070109 Status: RO Content-Length: 313 Nicolas Williams wrote: >>Yes - something like "/usr/share/info:/usr/sfw/share/info:...". >> >> > >Doesn't SMF support multi-valued properties? > > Yes, and as I now see from the doc that Gary referred to, the guidence calls for multi-valued properties to be used, so that's what this will be. - Dermot From Garrett.Damore@Sun.COM Mon Jun 25 10:01:14 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5PH1DL1016680 for ; Mon, 25 Jun 2007 10:01:13 -0700 (PDT) Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l5PGxWdH002334 for ; Mon, 25 Jun 2007 09:59:32 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l5PGxRdt003471 for ; Mon, 25 Jun 2007 09:59:27 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JK700I01AUWGW00@fe-sfbay-09.sun.com> (original mail from Garrett.Damore@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Mon, 25 Jun 2007 09:59:27 -0700 (PDT) Received: from [192.168.251.21] ([76.174.83.55]) by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JK70071OB6E9980@fe-sfbay-09.sun.com>; Mon, 25 Jun 2007 09:59:02 -0700 (PDT) Date: Mon, 25 Jun 2007 09:56:37 -0700 From: "Garrett D'Amore" Subject: Re: PSARC/2007/375 - Info directory file update service In-reply-to: <20070625152032.GI28070@Sun.COM> Sender: Garrett.Damore@Sun.COM To: Nicolas Williams Cc: Casper.Dik@Sun.COM, Darren.Reed@Sun.COM, Michael Hunter , John.Fischer@Sun.COM, Stephen Hahn , Dermot McCluskey , PSARC-ext@sac.sfbay.sun.com Message-id: <467FF3C5.7010605@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <20070621120933.000049ea@localhost> <20070622155120.GB17730@eng.sun.com> <467BF1DD.9050407@sun.com> <20070622160630.GN28070@Sun.COM> <467BF5C7.9050008@sun.com> <20070622162928.GQ28070@Sun.COM> <20070622105207.0000295f@localhost> <467CCA7E.1020609@Sun.COM> <200706230825.l5N8Pbh4016702@dm-holland-02.uk.sun.com> <467D73AB.3060807@sun.com> <20070625152032.GI28070@Sun.COM> User-Agent: Thunderbird 2.0b2 (X11/20070227) Status: RO Content-Length: 1425 Nicolas Williams wrote: > [To what list to send these design discussions? psarc-ext seems > inappropriate.] > > On Sat, Jun 23, 2007 at 12:25:31PM -0700, Garrett D'Amore wrote: > >> Here's a wild thought. Why not have *man* trigger the rebuild on a >> windex if it finds the index file is out of date? Then its not >> something that is just sitting around. >> > > How can it know? Sure, if it stumbles on a manpage that is newer than > the windex then it knows, but if I never find that newer man page > because I can't find it with man -k... > Stat of of the man directories shows a newer time than the windex file. In other words, the directory changed, but the windex wasn't updated. Usually that means an update is needed. > >> The other idea is that it could be kicked off from installation >> scripts.... I like that. Or even better yet, instead of using installf, >> use installman or some new wrapper around installf that does the >> necessary additions to the windex file at installation time ... without >> a full rebuild. >> > > This could work, I think: make installf or pkgadd smart about mandirs or > infodirs, or what have you, and, when installed on a running system, do > the right thing. > > But also, it should be possible to do this with class action scripts and > postinstall scripts (if [ -z "$PKG_INSTALL_ROOT" ]; then ...). > Yes, I suppose so. -- Garrett From Dermot.McCluskey@Sun.COM Tue Jun 26 08:34:55 2007 Received: from sfbaymail2sca.sfbay.sun.com (sfbaymail2sca.SFBay.Sun.COM [129.145.155.42]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5QFYtY7021001 for ; Tue, 26 Jun 2007 08:34:55 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id l5QFX9FR003495 for ; Tue, 26 Jun 2007 08:33:10 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5QFX4d3008100 for ; Tue, 26 Jun 2007 15:33:04 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JK800G01ZZ3SU00@d1-emea-09.sun.com> (original mail from Dermot.McCluskey@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Tue, 26 Jun 2007 16:33:04 +0100 (BST) Received: from [129.156.220.40] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JK900LGP1UP5B18@d1-emea-09.sun.com>; Tue, 26 Jun 2007 16:32:57 +0100 (BST) Date: Tue, 26 Jun 2007 16:34:54 +0100 From: Dermot McCluskey Subject: Re: IPSARC/2007/375 - Info directory file update service In-reply-to: <200706221923.l5MJNZqh026410@marduk.eng.sun.com> Sender: Dermot.McCluskey@Sun.COM To: Gary Winiger Cc: John.Fischer@Sun.COM, PSARC-ext@sac.sfbay.sun.com Reply-to: Dermot.McCluskey@Sun.COM Message-id: <4681321E.8060401@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <200706221923.l5MJNZqh026410@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.0 (X11/20070508) Status: RO Content-Length: 970 Gary Winiger wrote: > o Is the service and its property intended to be administered? > > o What action/value_authorization is defined for this service? > > o Is there a modify_authorization defined for this service? > If so what is it? If not, perhaps one is needed. > >>> How does this service satisfy the SMF SAC policy? > >> Can you point me to that document? > > It's in the usual place: > http://opensolaris.org/os/community/arc/policies/SMF-policy/ Thanks for the pointer. Having reviewed that, and noting that there may be a related case in future dealing with manpages, I'd like to alter the proposal to use two new authorizations, as follows: action_authorization: solaris.smf.manage.docs value_authorization: solaris.smf.value.docs These new authorizations will be added to a new rights profile, "Documentation Management". I don't think a modify_authorization is needed for this service. Does that satisfy the RBAC requirements? - Dermot From Dermot.McCluskey@Sun.COM Tue Jun 26 08:41:45 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5QFfjYF021363 for ; Tue, 26 Jun 2007 08:41:45 -0700 (PDT) Received: from gmp-ea-fw-1.sun.com (gmpes-gis-mail-1.UK.Sun.COM [129.156.42.5]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5QFe1AC021610 for ; Tue, 26 Jun 2007 08:40:02 -0700 (PDT) Received: from d1-emea-09.sun.com (d1-emea-09.sun.com [192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id l5QFdurc009140 for ; Tue, 26 Jun 2007 15:39:56 GMT Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0JK9002011YME500@d1-emea-09.sun.com> (original mail from Dermot.McCluskey@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Tue, 26 Jun 2007 16:39:56 +0100 (BST) Received: from [129.156.220.40] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0JK900LJB26J5B58@d1-emea-09.sun.com>; Tue, 26 Jun 2007 16:39:56 +0100 (BST) Date: Tue, 26 Jun 2007 16:42:00 +0100 From: Dermot McCluskey Subject: Re: IPSARC/2007/375 - Info directory file update service In-reply-to: <467CCC2C.3000408@Sun.COM> Sender: Dermot.McCluskey@Sun.COM To: Darren.Reed@Sun.COM Cc: Bill Sommerfeld , John.Fischer@Sun.COM, PSARC-ext@sac.sfbay.sun.com Reply-to: Dermot.McCluskey@Sun.COM Message-id: <468133C8.4060404@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1182446083.52470.8.camel@sr1-umpk-55> <1182447930.1596.35.camel@localhost> <467BD306.1090807@Sun.COM> <467CCC2C.3000408@Sun.COM> User-Agent: Thunderbird 2.0.0.0 (X11/20070508) Status: RO Content-Length: 545 Darren.Reed@Sun.COM wrote: >> Yes - you would need to wait for the next reboot of the non-global >> zone to see it take effect. > > > I don't know about you, but to me this seems to be a major problem. > > Nothing should have to rebooted in order for documentation to be > updated after new files have been installed. The documentation itself will be available immediately, eg "info foo" will work. This is just updating the directory, so if you run "info" you won't be able to navigate to the foo doc until this service has run. - Dermot From gww@eng.sun.com Tue Jun 26 13:36:23 2007 Received: from engmail3mpk.sfbay.Sun.COM (engmail3mpk.SFBay.Sun.COM [129.146.11.26]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5QKaN5I012064 for ; Tue, 26 Jun 2007 13:36:23 -0700 (PDT) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by engmail3mpk.sfbay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5QKYcsL010092; Tue, 26 Jun 2007 13:34:38 -0700 (PDT) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id l5QKbXTb000015; Tue, 26 Jun 2007 13:37:33 -0700 (PDT) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id l5QKbXJi000014; Tue, 26 Jun 2007 13:37:33 -0700 (PDT) Date: Tue, 26 Jun 2007 13:37:33 -0700 (PDT) From: Gary Winiger Message-Id: <200706262037.l5QKbXJi000014@marduk.eng.sun.com> To: Dermot.McCluskey@Sun.COM, gww@eng.sun.com Cc: John.Fischer@Sun.COM, PSARC-ext@sac.sfbay.sun.com Subject: Re: IPSARC/2007/375 - Info directory file update service Status: RO Content-Length: 764 > manpages, I'd like to alter the proposal to use two new > authorizations, as follows: > action_authorization: solaris.smf.manage.docs > value_authorization: solaris.smf.value.docs > > These new authorizations will be added to a new > rights profile, "Documentation Management". > > I don't think a modify_authorization is needed for this service. > > > Does that satisfy the RBAC requirements? Likely. I can't say for sure without seeing something approaching a final spec. As Jim said a man page would be helpful. N.B. RBAC is not the only requirement in the SMF policy. There are manifest, method context, enabling, ... issues as well. Then there's the efficacy of the proposal. That is somewhat different than the delivery mechanism. Gary.. From John.Fischer@Sun.COM Wed Jun 27 10:11:40 2007 Received: from sfbaymail1sca.SFBay.Sun.COM (sfbaymail1sca.SFBay.Sun.COM [129.145.154.35]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id l5RHBeeD007229 for ; Wed, 27 Jun 2007 10:11:40 -0700 (PDT) Received: from sca-es-mail-2.sun.com (sca-es-mail-2.Sun.COM [192.18.43.133]) by sfbaymail1sca.SFBay.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id l5RH9vjR010693 for ; Wed, 27 Jun 2007 10:09:57 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id l5RH9qJL026451 for ; Wed, 27 Jun 2007 10:09:52 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JKA00E01YRD6Y00@fe-sfbay-09.sun.com> (original mail from John.Fischer@Sun.COM) for PSARC-ext@sac.sfbay.sun.com; Wed, 27 Jun 2007 10:09:52 -0700 (PDT) Received: from [129.150.12.240] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JKB005ZB1066R30@fe-sfbay-09.sun.com> for PSARC-ext@sac.sfbay.sun.com; Wed, 27 Jun 2007 10:09:42 -0700 (PDT) Date: Wed, 27 Jun 2007 10:08:52 -0700 From: John Fischer Subject: Re: IPSARC/2007/375 - Info directory file update service In-reply-to: <200706262037.l5QKbXJi000014@marduk.eng.sun.com> Sender: John.Fischer@Sun.COM To: Dermot.McCluskey@Sun.COM Cc: PSARC-ext@sac.sfbay.sun.com Message-id: <468299A4.6040001@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <200706262037.l5QKbXJi000014@marduk.eng.sun.com> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.7) Gecko/20051027 Status: RO Content-Length: 970 Dermot, I have placed this case into waiting need spec. Once you have updated us with the new functional specification we can reset the timer. Thanks, John Gary Winiger wrote: >>manpages, I'd like to alter the proposal to use two new >>authorizations, as follows: >>action_authorization: solaris.smf.manage.docs >>value_authorization: solaris.smf.value.docs >> >>These new authorizations will be added to a new >>rights profile, "Documentation Management". >> >>I don't think a modify_authorization is needed for this service. >> >> >>Does that satisfy the RBAC requirements? > > > Likely. I can't say for sure without seeing something > approaching a final spec. As Jim said a man page would > be helpful. > > N.B. RBAC is not the only requirement in the SMF policy. > There are manifest, method context, enabling, ... issues > as well. Then there's the efficacy of the proposal. That > is somewhat different than the delivery mechanism. > > Gary..