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.