On 2024/01/23 09:56, Robert Nagy wrote:
> On 23/01/24 07:39 +0000, Stuart Henderson wrote:
> > On 2024/01/23 07:10, Jason McIntyre wrote:
> > > On Tue, Jan 23, 2024 at 07:07:01AM +0000, Stuart Henderson wrote:
> > > > On 2024/01/22 21:55, Matthew Martin wrote:
> > > > > The command to generate the cap db when login.conf.d is in use isn't
> > > > > immediately obvious as login.conf.d takes precedence which then
> > > > > necessitates the use of -f. Add example to login.conf.5 matching the
> > > > > example without login.conf.d. Command courtesy of Sol?ne.
> > > > 
> > > > I strongly recommend against doing this. When a package is updated to
> > > > a version with a different login.conf.d file, the old db file will
> > > > override the newly updated text file, so the changes won't take effect.
> > > > 
> > > 
> > > well, login.conf(5) says:
> > > 
> > >      Note that cap_mkdb(1) must be run after each edit of /etc/login.conf or
> > >      the /etc/login.conf.d/${class} file to keep the database version in sync
> > >      with the plain file.
> > 
> > I don't think that goes far enough really - will anyone think that
> > "edit" also includes "run pkg_add" in some cases?
> > 
> > > so maybe we should be more active in not suggesting this route for
> > > login.conf.d (if, as you say, it is not recommended).
> > 
> > That would seem a good idea to me. There are already plenty of ways
> > people can store up trouble for their future selves without us
> > suggesting new ones :)
> > 
> 
> Honesltly, I would completely remove support for the database versions
> of these files as I do not see the benefit of them at all with login.conf(5),
> they just overcomplicate things for no reason at all.
> 

I'd prefer that. The db files might have mattered 25 years ago on a busy
system but they seem to be an anachronism now.

But if we don't do that, then I'm ok with jmc's manpage diff.