Re: Status of updatedb

[James Youngman]

On 4/21/06, Miloslav Trmac <address@hidden> wrote:

> This particular wheel can't be easily used for the findutils car without
> changing the findutils' interface, which I assume isn't desirable:
> - locate(1) had to be compatible with slocate and thus the locate
>   interface conflicts, at least in the -r option semantics.

The -r options are incompatible?   I didn't know.  How, exactly?

> - mlocate uses the slocate's concept of scanning as root and having
>   a privileged group for locate; extending findutils' updatedb to
>   handle both this model and the traditional "run find as nobody"
>   model (for backward compatibility) would be IMHO rather ugly.
> - mlocate's updatedb tries hard to skip reading directories, so
>   updatedb.sh --findoptions can't be easily implemented, at least
>   not without dropping to a "slow mode" and reimplementing most of
>   find(1) in the meantime.  This could probably be solved by strongly
>   tying together find and updatedb in findutils.

findutils' current updatedb is ugly and not as robust as it could be. 
 In particular there are pipelines where failure of an intermediate
stage is not detected.

> That said, I would be happy to work with you on integrating the code as
> far as possible, e.g. getting most of the code in findutils as a shared
> library, and leaving mlocate as a tiny wrapper.

Better compatibility between findutils and slocate will be a proposed
project for the Google Summer of Code 2006.  It's something the GNU
project is interested in pursuing.   We'll see how the SoC thing goes
(no idea if any students will pick that one up).  But generally I'm
interested in pursuing this, yes.

James.