is there any value to pruning /udev in /etc/updatedb.conf?

is there any value to pruning /udev in /etc/updatedb.conf?

just noticed in /etc/updatedb.conf in F27, the snippet:

PRUNEPATHS = "... /udev ..."

not sure if /udev ever existed in fedora, but i think it's safe to
say, it's not there now and probably won't be any time in the near
future. and even though it doesn't *hurt* to have extraneous directory
names in that list, is there any compelling reason to keep it there?

Re: is there any value to pruning /udev in /etc/updatedb.conf?

On 03/06/18 04:51, Robert P. J. Day wrote:
> just noticed in /etc/updatedb.conf in F27, the snippet:
>
> PRUNEPATHS = "... /udev ..."
>
> not sure if /udev ever existed in fedora, but i think it's safe to
> say, it's not there now and probably won't be any time in the near
> future. and even though it doesn't *hurt* to have extraneous directory
> names in that list, is there any compelling reason to keep it there?
>
You probably don't have /net, /var/spool/squid on your system. But you may know of a
package or process that would create them. So, removing them may cause an issue for
you should you make changes to your system at some point. The same could possibly be
said about /udev.

Making changes for the sake of making changes is rarely a good idea.

--
If simple questions can be answered with a simple google query then why are there so
many of them?

Re: is there any value to pruning /udev in /etc/updatedb.conf?

On Tue, 6 Mar 2018, Ed Greshko wrote:

> On 03/06/18 04:51, Robert P. J. Day wrote:
> > just noticed in /etc/updatedb.conf in F27, the snippet:
> >
> > PRUNEPATHS = "... /udev ..."
> >
> > not sure if /udev ever existed in fedora, but i think it's safe to
> > say, it's not there now and probably won't be any time in the near
> > future. and even though it doesn't *hurt* to have extraneous
> > directory names in that list, is there any compelling reason to
> > keep it there?
> >
> You probably don't have /net, /var/spool/squid on your system. But
> you may know of a package or process that would create them. So,
> removing them may cause an issue for you should you make changes to
> your system at some point. The same could possibly be said about
> /udev.

it's only the mlocate database, i doubt incorrect output is going to
cause any system issues. :-)

> Making changes for the sake of making changes is rarely a good idea.

i realize change for the sake of change is not necessarily a good
plan, but i don't recall udev *ever* creating a top-level /udev
directory (maybe i just missed it). i'm also sure that such a
directory would be unsupported by the current incarnation of udev.

i understand there's no actual harm in having extraneous directories
in that list, but various linux vendors tweak packages all the time
for their particular distros. for instance, "man updatedb.conf" on my
fedora 27 system claims:

PRUNEPATHS
A whitespace-separated list of path names of directories which
should not be scanned by updatedb(8). Each path name must be
exactly in the form in which the directory would be reported
by locate(1).

By default, no paths are skipped. <------------ there

and yet, my current /etc/updatedb.conf (which i have never modified to
the best of my knowledge), contains:

Re: is there any value to pruning /udev in /etc/updatedb.conf?

On 03/06/18 18:29, Robert P. J. Day wrote:

> On Tue, 6 Mar 2018, Ed Greshko wrote:
>
>> On 03/06/18 04:51, Robert P. J. Day wrote:
>>> just noticed in /etc/updatedb.conf in F27, the snippet:
>>>
>>> PRUNEPATHS = "... /udev ..."
>>>
>>> not sure if /udev ever existed in fedora, but i think it's safe to
>>> say, it's not there now and probably won't be any time in the near
>>> future. and even though it doesn't *hurt* to have extraneous
>>> directory names in that list, is there any compelling reason to
>>> keep it there?
>>>
>> You probably don't have /net, /var/spool/squid on your system. But
>> you may know of a package or process that would create them. So,
>> removing them may cause an issue for you should you make changes to
>> your system at some point. The same could possibly be said about
>> /udev.
> it's only the mlocate database, i doubt incorrect output is going to
> cause any system issues. :-)

Not saying any "incorrect" output would result or there would be any "system
issues". But let's say you remove it from the prune list and a device gets mounted
on that point that contains a large file system with many small files. Then you may
be scratching your head wondering why your system is suddenly busy at times.

>
>> Making changes for the sake of making changes is rarely a good idea.
> i realize change for the sake of change is not necessarily a good
> plan, but i don't recall udev *ever* creating a top-level /udev
> directory (maybe i just missed it). i'm also sure that such a
> directory would be unsupported by the current incarnation of udev.
>
> i understand there's no actual harm in having extraneous directories
> in that list, but various linux vendors tweak packages all the time
> for their particular distros. for instance, "man updatedb.conf" on my
> fedora 27 system claims:
>
> PRUNEPATHS
> A whitespace-separated list of path names of directories which
> should not be scanned by updatedb(8). Each path name must be
> exactly in the form in which the directory would be reported
> by locate(1).
>
> By default, no paths are skipped. <------------ there
>
> and yet, my current /etc/updatedb.conf (which i have never modified to
> the best of my knowledge), contains:
>
> PRUNEPATHS = "/afs /media /mnt /net /sfs /tmp /udev /var/cache/ccache
> /var/lib/yum/yumdb /var/lib/dnf/yumdb /var/spool/cups
> /var/spool/squid /var/tmp /var/lib/ceph"
>
> so it would seem that red hat is already customizing that file in
> contrast to what the man page says. just pointing out that red hat is
> already making some changes here.
>

There is no ambiguity in the man page. What the man page is saying is that in the
absence of a PRUNEPATHS being specified no paths are skipped. The same goes for
PRUNEFS. Without that specified all fs types will be searched. It is then up to the
packager, or distro, to decide what makes sense for them and to define things
accordingly.

The same thing goes for all config files, actually. You'll read the man page and it
defines a given feature and what the default setting it. And, you *may* then look at
the config file and find that the default value/setting has been changed. Those in
charge package or distro have decided what is "best".

You want to change it? Go ahead. I make changes all the time to the "distro default
settings". Like sshd, I don't allow passwords for authentication. Only keys.

--
If simple questions can be answered with a simple google query then why are there so
many of them?