On Sun, 24 May 2009, Craig Sanders wrote:
On Sun, May 24, 2009 at 10:20:37AM +0200, Tomas Pospisek wrote:
Coming from Ubuntu and having installed dlocate, I've had locate -
required by dlocate - and mlocate - superior disk access an installed
by default by Ubuntu - trash my disks daily for a year or two.
I've iterated a bit through #494673 and the related discussion in
#454106 however I do not get it.
The README in #494673 suggests disabling the daily
locate disk trash run, which I now did. James Youngman
suggest somewhere in the middle of the #454106 discussion
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454106#10) to
instead generate the locate DB from the mlocate DB.
yes, both of these things are possible.
If I check /usr/sbin/update-dlocatedb (dlocate!) I see the locate DB
referenced but no mention of mlocate there. So I'd assume, that once I
dlocate does not and can not use mlocate. mlocate does not provide the
frcode program which dlocate requires, nor does it provide even a rough
equivalent of it. mlocate works completely differently to locate.
BTW, the locate DB referenced in that script is dlocate's own db...it
is not shared with locate, it is completely unrelated data that just
happens to be in the same format as locate's db (because it is made with
the same frcode tool).
OK, that clears things up for me. Good.
have switched off the locate run, this would stop updating the locate
DB and since dlocate is using the locate DB this would also stop
updating the dlocate DB. Is this correct or am I confused?
dlocate doesn't use locate's own db. it only uses some of the
programs(*) which used to be in the findutils package but are now in a
separate 'locate' package.
you can disable the locate package's cron job completely and it will not
affect dlocate in any way. as mentioned, it does not use the locate db,
it uses it's own db (/var/lib/dlocate/dlocatedb)
(*) specifically /usr/bin/locate and /usr/lib/locate/frcode
Could this later point be made clear in the README?
i really don't know how it could be said any clearer.
I suggest actually putting that information somewhere into the package as
for example into the README.Debian.
And could the README be included in the dlocate package please? I'm
thinking it could spare the world a few dozen kilo joule of electricity
over all?
what README? There is a README.Debian in the dlocate package.
$ dpkg -s dlocate | grep Version
Version: 0.96.1
so that's the same one as in sid and should be the latest available as far
as I'm aware. Now let's check the README.Debian (previously unprecisely
called README by myself):
$ cat /usr/share/doc/dlocate/README.Debian
dlocate for Debian
----------------------
fast alternative to 'dpkg -L', 'dpkg -S' etc.
NOTE: the 'dlocate -l' is NOT the same as 'dpkg -l' and i will ignore
bug reports which point out this obvious fact.
it is a simplistic emulation, not an exact clone.
IMO, it is more useful than 'dpkg -l'. if you disagree, then you are
free to use the slower original.
-- Craig Sanders <[email protected]>, Tue, 2 Nov 1999 17:21:03 +1100
No mention of disabling locate's updatedb run here.
dlocate will install locate by dependency and locate will by default start
automatically trashing the disk each day. Thus in my opinion dlocate
should warn the user of this. I'd suggest putting a line into dlocate's
manpage referring to the README.Debian and explain things there.
Additionally I'd suggest to test in the dlocate.postinst whether either
two of locate and mlocate or slocate are installed and tell the user that
he probably wants to disable the locate updatedb run through the
/etc/updatedb.findutils.cron.local mechanism.
If you agree in principle with this then I can send you a patch.
Either way, thanks for this reply Craig,
*t
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
