Re: bin/60049: apm manpages and RC script installed everywhere

["Valery Ushakov via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR bin/60049; it has been noted by GNATS.

From: Valery Ushakov <uwe%stderr.spb.ru@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/60049: apm manpages and RC script installed everywhere
Date: Wed, 4 Mar 2026 05:14:08 +0300

 On Tue, Mar 03, 2026 at 22:20:02 +0000, David H. Gutteridge via gnats wrote:
 
 >  I can't speak for the submitter, but to me the point isn't about saving
 >  space, the point is this is bad UX for a user to get a man page or see
 >  a config file for a component that cannot work on the port they're
 >  running.
 
 To go from "cannot" to "can" all you need is to write a driver (a
 loadable kernel module) that talks rather simple apm(4) ioctls.  Say,
 hpcsh doesn't have APM BIOS obviously, yet there's a device that talks
 apm(4).  hpcsh j6x0pwr.c is like 300 lines of pretty sparse code, half
 of which is probably boilerplate.  May be some day macal^Wsomeone will
 fancy writing one for old macppc powerbooks (just a random example) -
 and the userland part is already there.  As far as I recall, when I
 wrote j6x0pwr.c I didn't have to do anything to get apm(8), so I think
 I can reasonably claim BTDT on that one.
 
 May be today there are better ways to do that (envsys or something),
 but I don't think that presense of apm causes much of a moral panic.
 
 PS: Can macppc ever use hdaudioctl(8)?  hdaudio(4) is not in any of
 its kernel configs.  (I honestly don't know; I guess you can use a PCI
 card in a mac pro...)
 
 -uwe