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

["David H. Gutteridge via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/60049: apm manpages and RC script installed everywhere
Date: Tue, 03 Mar 2026 17:16:08 -0500

 On Tue, 3 Mar 2026 at 19:40:01 +0000 (UTC), Valery Ushakov wrote:
 >>  You're saying that it would also be necessary to have it in
 dedicated
 >>  subdirectories for arm, hpcsh, macppc, and sparc?
 >
 > The established practice is to install all port-specific subdirs.  I'm
 > pretty sure the reason it was moved out of i386 was exactly to avoid
 > that duplication.  You are now effectively proposing to undo that
 > change.
 
 Sorry, how exactly is the submitter proposing to create duplication (in
 source-controlled man pages and config files)? The proposal is to
 create md-specific lists for these files, like we do for other content.
 The man pages and such would be single copies. We would have better,
 more fine-grained control over what port installs what than we do
 today.
 
 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. Yes, we've always installed all the port-specific man pages
 under section 8 everywhere, but that doesn't make that a great choice,
 either, simply historical baggage.
 
 (From what I see, some of the historical changes in question out of
 i386 weren't to avoid duplication, they were simply that we didn't have
 the means available at the time that the submitter is proposing, and
 the hack/solution was to just install stuff indiscriminately.)
 =20
 >>  What purpose do these port-specific directories serve that is not
 >>  served by simply delivering the items in question to the ports
 >>  where they are relevant and not delivering them to the ports where
 >>  they should not exist?
 =20
 > syspkgs never really landed so I'd day we are mostly chill about an
 > extra file or two that might not be strictly speaking necessary on a
 > given system.  Any churn that solves one particular instance, but
 > doesn't address the problem is general is worse, IMO.
 
 But this *is* intended to solve the general problem, no? I don't see
 why we should dismiss this outright.
 
 Regards,
 
 Dave