[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Opinions sougth: mlocate appropriate for Priority: standard?



Hello.

I'm preparing packages for mlocate, and personally I would like to
upload it with Priority: standard. But I'm open to be convinced that is
not a good idea (eg. "standard is already bloated").

I think having a working /usr/bin/locate is a reasonable expectation for
a Linux system nowadays, so the priority level would fit. I am aware of
course that findutils already provides one implementation, and it's
Priority: required...

However, I would very much like to have a *better* implementation
installed by default, and I think mlocate would be very appropriate for
the job:

  * as slocate, it runs and root instead of nobody in order to index all
    files, but keeps it's database mode 640 root:mlocate, and a setgid
    binary /usr/bin/locate in order to only return results the running
    user has access to

  *and*

  * mlocate keeps timestamps in its database, so when running updatedb
    it can determine if the contents of a directory have changed without
    having to read its contents; this makes the update faster, and less
    demanding on the harddist (that's where the name comes from, "merge
    locate")

mlocate is written by a RedHat person, is maintained upstream (unlike,
it seems, slocate), and if I'm not mistaken is already default in Fedora.

Opinions?

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
When it is not necessary to make a decision, it is necessary not to make
a decision.



Reply to: