From G.@speed Mon Jun 3 08:29:49 1991 Return-Path: Received: from Eng.Sun.COM (zigzag) by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA08297; Mon, 3 Jun 91 08:29:46 PDT Received: from opus.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA07069; Mon, 3 Jun 91 08:29:42 PDT Received: from speed.Eng.Sun.COM by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA08294; Mon, 3 Jun 91 08:29:40 PDT Received: from opus.Eng.Sun.COM by speed.Eng.Sun.COM (4.1/SMI-4.1) id AA26021; Mon, 3 Jun 91 08:29:37 PDT Date: Mon, 3 Jun 91 08:29:37 PDT From: G.@speed (Rob G.) Message-Id: <9106031529.AA26021@speed.Eng.Sun.COM> To: plat.sw.arc@opus Subject: Manual packaging Status: R This is psarc/1991/033. ----- Begin Included Message ----- Date: Sun, 2 Jun 91 23:57:40 PDT From: jah@caps (Judy H.P.) Message-Id: <9106030657.AA22861@caps.Eng.Sun.COM> To: G.@speed Subject: Re: PSARC schedule Cc: jackh@twinpeaks, jah@caps Status: R >Send me a write-up describing the proposed structure. There's no specific >format, just gimme whatever you got. I'll send it to the group and we'll >let you know if we need a meeting -- otherwise, we'll just do it all through >mail and get done quicker. Rob, Here's the proposal I wrote up. It's a brief sketch, please let me know if you need more details. Thanks! Judy =========================================== Below is a proposal on how the Jupiter Reference Manual and the 'manpage' software package will reflect the new packaging structure of the WOS. Historically (SunOS releases up to 4.1.y), the Reference Manual and /usr/man contained man pages to document the entire OS. Optionally installable pieces of the OS (for example, System V, Text Processing, etc.) were included, but those pages contained AVAILABILITY sections specifying the software installation category. Man pages for unbundled products were shipped with the unbundled documentation only, and their man pages were installed to a directory tree other than /usr/man. In Zeus, the Reference Manual and the 'manpage' package contained all man pages *except* OpenWindows and previously unbundled products (SNL, Fortran, XGL, etc). For Jupiter, we propose that the Reference Manual and the 'manpage' package (installed to /usr/man) contain man pages for components that meet *both* of the following conditions: 1) They have traditionally been in the OS. *AND* 2) They are bundled with Jupiter. Some examples: OpenWindows will not be included in this package since it has not traditionally been part of the OS. The C compiler has traditionally been in the OS, but it is not bundled with Jupiter, therefore it will not be included in this package either. (The "casual" compiler man page will be, though.) SCCS has traditionally been in the OS, and is bundled with Jupiter, therefore, it will be included in this package. Man pages not included in the 'manpage' package will be included in the software package for their product, and they will be installed to $INSTALLDIR/man. For example, if OpenWindows is installed in /opt/openwin, their man pages will be installed in /opt/openwin/man. To make this structure (/usr/man and $INSTALLDIR/man) transparent to our customers, the global start up files will set a default MANPATH to include all man pages available with Jupiter. Engineering effort: If possible, this path should be set by determining which packages have actually been installed, and only those paths should be added to this variable. The AVAILABILITY section will be used to associate man pages with the package containing their software. The Reference Manual will clearly explain what components it documents, and will provide pointers to other relevant man pages not included (for example, OpenWindows). Please let me know if you have any questions or comments about this proposal. Thanks for your time and consideration. Judy ----- End Included Message ----- From sE.@alydar Mon Jun 3 09:18:57 1991 Return-Path: Received: from Eng.Sun.COM (zigzag) by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA08392; Mon, 3 Jun 91 09:18:55 PDT Received: from opus.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA08857; Mon, 3 Jun 91 09:18:52 PDT Received: from alydar.Eng.Sun.COM by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA08389; Mon, 3 Jun 91 09:18:51 PDT Received: from window.Eng.Sun.COM by alydar.Eng.Sun.COM (4.1/SMI-4.1) id AA19486; Mon, 3 Jun 91 09:18:41 PDT Date: Mon, 3 Jun 91 09:18:41 PDT From: sE.@alydar (Steve E.) Message-Id: <9106031618.AA19486@alydar.Eng.Sun.COM> Received: by window.Eng.Sun.COM (4.1/SMI-4.1) id AA14240; Mon, 3 Jun 91 09:18:46 PDT To: plat.sw.arc@opus Subject: Re: Manual packaging Cc: jah@caps, jackh@twinpeaks Status: R OpenWindows will not be included in this package since it has not traditionally been part of the OS. Another way to look at it is that SunWindows/SunView has traditionally been packaged with the OS. This implies that a/the window system manpages have traditionally been packaged with the OS. On this basis, due to SunView starting to be EOLed in SunOS 5.0 and OpenWindows taking its place, one could argue that following tradition, we should package the window system documentation with the OS. Whether we actually want to do this or not is another thing. But I think that the logic of not associating OpenWindows with the historical tradition of SunView is flawed. sE. From R.@vijnana Mon Jun 3 11:32:03 1991 Return-Path: Received: from Eng.Sun.COM (zigzag) by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA08626; Mon, 3 Jun 91 11:32:02 PDT Received: from opus.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA14588; Mon, 3 Jun 91 11:31:57 PDT Received: from vijnana.Eng.Sun.COM by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA08623; Mon, 3 Jun 91 11:31:55 PDT Received: by vijnana.Eng.Sun.COM (4.1/SMI-4.1) id AA03960; Mon, 3 Jun 91 11:32:09 PDT Date: Mon, 3 Jun 91 11:32:09 PDT From: R.@vijnana (Jarrett R.) Message-Id: <9106031832.AA03960@vijnana.Eng.Sun.COM> To: plat.sw.arc@opus Subject: Re: Manual packaging Cc: R.@Eng Status: RO The proposal sounds reasonable enough, except that every time I install something, I'll have to edit my MANPATH. Since we're going to all the trouble of having unbundled software always go in /opt, how about just having one /opt/man directory instead numerous /opt//man ones? Then the default MANPATH could be just "/usr/man:/opt/man". Jarrett From glenn@ivrel Mon Jun 3 14:25:33 1991 Return-Path: Received: from Eng.Sun.COM (zigzag) by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA09023; Mon, 3 Jun 91 14:25:30 PDT Received: from opus.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA23781; Mon, 3 Jun 91 14:25:28 PDT Received: from ivrel.Eng.Sun.COM by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA09020; Mon, 3 Jun 91 14:25:26 PDT Received: by ivrel.Eng.Sun.COM (4.1/SMI-4.1) id AA01278; Mon, 3 Jun 91 14:25:54 PDT Date: Mon, 3 Jun 91 14:25:54 PDT From: glenn@ivrel (Glenn C. Skinner) Message-Id: <9106032125.AA01278@ivrel.Eng.Sun.COM> To: plat.sw.arc@opus Subject: Re: Manual packaging Status: R From R.@vijnana Mon Jun 3 11:32:33 1991 Date: Mon, 3 Jun 91 11:32:09 PDT From: R.@vijnana (Jarrett R.) To: plat.sw.arc@opus Subject: Re: Manual packaging Cc: R.@Eng The proposal sounds reasonable enough, except that every time I install something, I'll have to edit my MANPATH. Since we're going to all the trouble of having unbundled software always go in /opt, how about just having one /opt/man directory instead numerous /opt//man ones? Then the default MANPATH could be just "/usr/man:/opt/man". On the other hand, installing all unbundled man pages into /opt/man has the unfortunate consequence that package name spaces are no longer distinct. We could (perhaps) manage this name space for packages that we control, but we have no hope of doing so for ones we don't. Note also that avoiding collisions in man page names requires corresponding measures applied to command names. I shudder to think of the logistics of keeping command names distinct across all packages. (The "prepend the company's stock symbol" disambiguator doesn't cut it in this context.) Thus, despite the MANPATH editing problem, I think per-package man directories are a practical necessity. A partial solution to this problem would be to recommend that package installation scripts edit /etc/{profile,.login} to append their man directory path to a default MANPATH definition kept there. This approach certainly isn't ideal; it doesn't help users who maintain their own MANPATH definition and it doesn't cope with packages mounted over the network. I think it's somewhat better than nothing, though. -- Glenn From R.@vijnana Mon Jun 3 14:49:24 1991 Return-Path: Received: from Eng.Sun.COM (zigzag) by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA09077; Mon, 3 Jun 91 14:49:22 PDT Received: from opus.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA25424; Mon, 3 Jun 91 14:49:10 PDT Received: from vijnana.Eng.Sun.COM by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA09074; Mon, 3 Jun 91 14:48:58 PDT Received: by vijnana.Eng.Sun.COM (4.1/SMI-4.1) id AA04870; Mon, 3 Jun 91 14:49:08 PDT Date: Mon, 3 Jun 91 14:49:08 PDT From: R.@vijnana (Jarrett R.) Message-Id: <9106032149.AA04870@vijnana.Eng.Sun.COM> To: plat.sw.arc@opus Subject: Re: Manual packaging Cc: R.@Eng Status: R Oh yeah, name clashes; yuck. I still can't resign myself to forcing users to edit MANPATH each time they install something, though. How about, instead of "/opt//man/", we have "/opt/man//"? Then we just need man to automatically search all the subdirs in /opt/man. Will that work? Jarrett From S.@datsun Mon Jun 3 16:01:34 1991 Return-Path: Received: from Eng.Sun.COM (zigzag) by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA09214; Mon, 3 Jun 91 16:01:32 PDT Received: from opus.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA29885; Mon, 3 Jun 91 16:01:21 PDT Received: from datsun.Eng.Sun.COM by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA09211; Mon, 3 Jun 91 16:00:33 PDT Received: by datsun.Eng.Sun.COM (4.1/SMI-4.1) id AA13562; Mon, 3 Jun 91 16:00:33 PDT Date: Mon, 3 Jun 91 16:00:33 PDT From: S.@datsun (Bill S.) Message-Id: <9106032300.AA13562@datsun.Eng.Sun.COM> To: plat.sw.arc@opus Subject: Re: Manual packaging Status: R I agree with Steve's comments about OpenWindows. I think that all parts of the system should have their man pages in /usr/man. If you get it when you buy "SunOS", it should be in /usr/man. If you pay extra for it, it should be in /opt//man. I really hate using environment variables to hold defaults, since it makes it hard to change defaults for already running processes. I'd rather not use a per-process mechanism to specify a system-wide default. But given that that may be too big a change to make, it would seem to be simple enough to have (e.g.) /etc/profile construct a MANPATH from /usr/man and /opt/*/man. From glenn@ivrel Tue Jun 4 16:45:56 1991 Return-Path: Received: from Eng.Sun.COM (zigzag) by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA10980; Tue, 4 Jun 91 16:45:54 PDT Received: from opus.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA12202; Tue, 4 Jun 91 16:45:46 PDT Received: from ivrel.Eng.Sun.COM by opus.Eng.Sun.COM (4.1/SMI-4.1) id AA10977; Tue, 4 Jun 91 16:45:45 PDT Received: by ivrel.Eng.Sun.COM (4.1/SMI-4.1) id AA02813; Tue, 4 Jun 91 16:46:12 PDT Date: Tue, 4 Jun 91 16:46:12 PDT From: glenn@ivrel (Glenn C. Skinner) Message-Id: <9106042346.AA02813@ivrel.Eng.Sun.COM> To: plat.sw.arc@opus Subject: Re: Manual packaging Status: RO From R.@vijnana Mon Jun 3 14:49:55 1991 Date: Mon, 3 Jun 91 14:49:08 PDT From: R.@vijnana (Jarrett R.) To: plat.sw.arc@opus Subject: Re: Manual packaging Oh yeah, name clashes; yuck. I still can't resign myself to forcing users to edit MANPATH each time they install something, though. How about, instead of "/opt//man/", we have "/opt/man//"? Then we just need man to automatically search all the subdirs in /opt/man. Will that work? It won't work without changing the man command. Moreover, I don't see how to do so in a way that preserves compatibility and has reasonably clean search semantics. -- Glenn