Hook whichlocker into command-not-found

[broder]

It shouldn't be too hard to generate a command-not-found database from the whichlocker database. Someone should do this.

[jdreed]

I looked a the source, things like "packages" and "apt-get install" are hardcoded. We could hack it, of course, but I wonder how maintainable that would be. It seems like it would be simpler to just change the command_not_found bash hook, and have it run whichlocker first, and then run /usr/lib/command-not-found. We already divert /etc/bash.bashrc, so we'd just need to add our own hook after we source Ubuntu's stock bashrc.

Something like this should work:

function command_not_found_handle {
    if [ -x /mit/outland/arch/@sys/bin/whichlocker ]; then
	WARNED=1 /mit/outland/arch/@sys/bin/whichlocker $1
    fi
    if [ -x /usr/lib/command-not-found ]; then
	/usr/bin/python /usr/lib/command-not-found -- $1
	return $?
    else
	return 127
    fi
}

We probably want to tweak it. I initially have WARNED=1 because the warning that whichlocker generates can get annoying after a while. We probably want to display our own text.

I wonder if the right thing to do is patch whichlocker to take a command line option to display the information in a format we want. Then we can do something like:

function command_not_found_handle {
    if [ -x /mit/outland/arch/@sys/bin/whichlocker ]; then
	INLOCKER=`WARNED=1 /mit/outland/arch/@sys/bin/whichlocker $1`
	if [ ! -z "$INLOCKER" ]; then
	   echo "Found in the following Athena lockers:"
	   echo $INLOCKER
	fi
    fi
    if [ -x /usr/lib/command-not-found ]; then
	/usr/bin/python /usr/lib/command-not-found -- $1
	return $?
    else
	return 127
    fi
}

I want the output to be informative but minimal if a program is both in an Athena locker and in the apt repository (eg, drscheme)

Relatedly, it would probably be a good idea to generate a command-not-found database for the debathena repository.

[andersk]

This has been pointed out on Zephyr, and is probably obvious anyway, but for the record: the outland locker should not be trusted for anything under any circumstances. A hook that runs whichlocker out of the outland locker would be a huge security problem. Even a hook that locally copies the whichlocker database needs to present this information very carefully to the user to avoid potentially misleading them. Also, even if whichlocker is moved to a more trusted locker (it’s not clear that debathena-standard users necessarily want to trust any locker), running something out of AFS is a performance problem; it could result in long freezes if AFS is unavailable.

[jdreed]

Yeah, I'm not saying we should do it, I'm pointing out that overriding the command_not_found_handle is easier and more feasible than a command-not-found database.

In addition to what Anders points out, there's the problem of bitrotted stuff too. Choosing to run "latex" out of the newtex locker rather than installing texlive has serious implications. Perhaps the right thing to do is search whichlocker if /usr/lib/command-not-found doesn't come up with anything.

Or we (defined as some combination of IS&T and Debathena folks) should possibly come up with our own locker database, which we install locally, and use that instead. Updates are cheap now, so it wouldn't be a hassle to keep it updated, especially if the number of lockers is small.

This probably requires a lot more thinking, and can happen later in the term.

[jhamrick]

In r24000, I created a custom command_not_found_handle (sourced in the method discussed in trac #214) which utilizes the whichlocker command. It has a daily cronjob that copies the database from  https://debathena.mit.edu/auto/whichlocker-database (as opposed to outland). At the moment, the database is just a copy from the outland database, but we should have debuild generate the database from the correct script periodically. This functionality can be acquired by installing the debathena-command-not-found package.

This still leaves the problem of reporting that a certain program is in a locker that it really shouldn't be run out of. (e.g. 'neo' is in the 'ktools' locker vs 'neo' is in the 'rescomp' locker)

[broder]

Replying to jhamrick:

This still leaves the problem of reporting that a certain program is in a locker that it really shouldn't be run out of. (e.g. 'neo' is in the 'ktools' locker vs 'neo' is in the 'rescomp' locker)

There's an easy solution to that - just punt ktools from the whichlocker database.

[jdreed]

Punting ktools only solves one problem. There are worse problems:

jdreed@infinite-loop:~$ athrun outland whichlocker gcc
Locker software on Athena is maintained by many different people.
Don't run this unless you know the maintainer can be trusted.
"gcc" is in "gcc-3.2" for linux and sun4
"gcc" is in "gcc-3.4" for linux and sun4
"gcc" is in "gcc-4.0" for linux and sun4
"gcc" is in "gnu" for linux and sun4
"gcc" is in "kde" for sun4

I wonder if now isn't the time to improve whichlocker, perhaps by indicating some sort of support level. Taking the previous examples, the gcc-n.n lockers get high values, the gnu locker gets medium values, and running gcc out of the kde locker is just plain wrong. I don't yet have a good idea for how to assign these values, or what the scale should be, but if users will now be getting whichlocker run on their behalf, we should maybe think about this.

There's probably also a separate project here, which is to get in touch with locker maintainers, and get them to punt or upgrade bitrotted software. This probably also ties in to #338.

[geofft]

Unassigning, since it's been idle for a while. If someone (including Jess) wants it back, feel free to claim it.