severity 489508 normal thanks On Sun, Jul 6, 2008 at 6:19 PM, Juhapekka Tolvanen <[EMAIL PROTECTED]> wrote: > On Sun, 06 Jul 2008, +20:26:40 EEST (UTC +0300), > Adeodato Simó <[EMAIL PROTECTED]> pressed some keys: > >> * Adeodato Simó [Sun, 06 Jul 2008 17:37:05 +0100]: >> >> > * Juhapekka Tolvanen [Sun, 06 Jul 2008 15:22:49 +0300]: >> >> > > texmacs depends on some locate-implementations, but mlocate can not be >> > > used. >> >> > texmacs has a Dependency on the "locate" package, so I'm not very sure >> > what the "important" bug is here... >> >> Oh, and it should be co-installable with mlocate. If not, that's a bug, >> but I don't think that's the case.
Texmacs is co-installable with mlocate. There is no problem there (unlike the title suggests). > > If somebody wants to install both texmacs and mlocate, he ends up > installing two (2) implementation of locate. Consider this situation. No locate packages have been installed to begin with. $ dpkg -l \*locate\* | grep ^ii Installig texmacs pulls in locate. $ sudo apt-get install texmacs Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: locate The following NEW packages will be installed locate texmacs 0 upgraded, 2 newly installed, 0 to remove and 1059 not upgraded. Need to get 149kB/1931kB of archives. After this operation, 6021kB of additional disk space will be used. Do you want to continue [Y/n]? Get: 1 http://ftp.us.debian.org sid/main locate 4.4.0-2 [149kB] Fetched 149kB in 0s (310kB/s) Selecting previously deselected package locate. (Reading database ... 141572 files and directories currently installed.) Unpacking locate (from .../locate_4.4.0-2_i386.deb) ... Selecting previously deselected package texmacs. Unpacking texmacs (from .../texmacs_1%3a1.0.6.14-1_i386.deb) ... Setting up locate (4.4.0-2) ... Installing new version of config file /etc/cron.daily/locate ... Setting up texmacs (1:1.0.6.14-1) ... $ dpkg -l \*locate\* | grep ^ii ii locate 4.4.0-2 maintain and query an index of a directory t In this case /usr/bin/locate would ultimately point to /usr/bin/locate.findutils $ ls -al /usr/bin/locate /etc/alternatives/locate /usr/bin/locate.findutils lrwxrwxrwx 1 root root 25 2008-07-06 23:15 /etc/alternatives/locate -> /usr/bin/locate.findutils lrwxrwxrwx 1 root root 24 2008-07-06 23:15 /usr/bin/locate -> /etc/alternatives/locate -rwxr-xr-x 1 root root 52668 2008-04-03 13:41 /usr/bin/locate.findutils Now install mlocate $ sudo apt-get install mlocate Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed mlocate 0 upgraded, 1 newly installed, 0 to remove and 1059 not upgraded. Need to get 0B/68.9kB of archives. After this operation, 406kB of additional disk space will be used. Selecting previously deselected package mlocate. (Reading database ... 141629 files and directories currently installed.) Unpacking mlocate (from .../mlocate_0.21-1_i386.deb) ... Setting up mlocate (0.21-1) ... You are right that there are two locate packages installed. $ dpkg -l \*locate\* | grep ^ii ii locate 4.4.0-2 maintain and query an index of a directory t ii mlocate 0.21-1 quickly find files on the filesystem based o But now /usr/bin/locate ultimately points to /usr/bin/mlocate and not to /usr/bin/locate.findutils . $ ls -al /usr/bin/locate /etc/alternatives/locate /usr/bin/locate.findutils /usr/bin/mlocate lrwxrwxrwx 1 root root 16 2008-07-06 23:18 /etc/alternatives/locate -> /usr/bin/mlocate lrwxrwxrwx 1 root root 24 2008-07-06 23:15 /usr/bin/locate -> /etc/alternatives/locate -rwxr-xr-x 1 root root 52668 2008-04-03 13:41 /usr/bin/locate.findutils -rwxr-sr-x 1 root mlocate 30432 2008-07-01 10:28 /usr/bin/mlocate So, I really do not see a problem here. > That wonderful feature is practically lost, if user of mlocate installs > texmacs: texmacs depends on some not-so-advanced implementations of > locate, that put useless stress on hard-drive. Hence, installing both > mlocate and some lousy implementation of locate is stupid, stupid and > once again stupid. The user will be using mlocate (from mlocate package) if he installs it or else he will be using locate (from locate package). I do not see why this is stupid. Are you suggesting that we should remove the dependency on locate package altogether and depend upon mlocate instead? > > In addition installing texmacs forces user to say goodbye to security. > Also this is from Description of mlocate: > > "it indexes all the filesystem, but results of a search will > only include files that the user running locate has access to. It does > this by updating the database as root, but making it unreadable for > normal users, who can only access it via the locate binary. slocate does > this as well, but not the original locate." Consider this situation. I am a normal user but with sudo powers. I do not want to use sudo powers unless necessary. I would like to see all the results of a search whether I can access them as user or not. If I am not able to access the file as a user, then I would use my "sudo powers" to access the file. However, I do not want to use sudo with every locate search command. You are suggesting the locate is insecure (compared to slocate and mlocate). It is probably superseded by one of these packages. In such a scenario, why not ask for its removal completely from Debian? What is the point of having an insecure package in the repository and saying it is stupid to depend on it? > > But texmacs forces to install some insecure implementation of locate. One possible solution would be to request the mlocate package maintainer to put a conflict on the locate package. If he is not willing to do that, then that means a user is free to have both. If a user can have both locate, mlocate side-by-side why should texmacs deprive him of that privilege? raju
