On Tue, 26 May 2009 22:10 +0300, "era eriksson" <e...@iki.fi> wrote: > In my opinion this is slightly problematic -- dlocate's install script > cannot know whether locate was installed explicitly by the user (well, I > suppose this information is available if you use aptitude, but not on a > plain apt-get/dpkg base system) or pulled in as a dependency. The > proper solution I guess would be for locate to be split into a > "locate-common" package containing the tools, keeping only the > configuration data in "locate" proper, but that sounds like severe > overkill. Many people do complain about unwanted locate runs so perhaps > there should be a bug about this against locate (sorry, too much in the > middle of something else to check right away whether there is one > already).
Incidentally, note also that slocate is no longer available (bug #457565). I suppose mlocate could check upon install whether locate is installed, and offer to disable or override its cron job (unsure whether it does this at the mo?) but that doesn't help in the scenario when mlocate is already installed and locate is pulled in as a dependency of dlocate. This is another scenario where a modular locate package could help. Then mlocate could Conflicts: locate and dlocate could Depends: locate-common without pulling in the potentially obnoxious cron job. Anyhow, this discussion is IMHO outside the scope of any bug of dlocate's. There is a bug #522143 against locate which is vaguely tangential to this discussion. Perhaps we should propose the break-up into locate-common and locate as a separate bug report? /* era */ -- If this were a real .signature, it would suck less. Well, maybe not. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
