Hey everyone. Thank you for your interest in command-not-found.
On Tue, Nov 14, 2017 at 8:50 AM, Julian Andres Klode <j...@debian.org> wrote: > (forwarding this to ubuntu-devel-discuss and Zygmunt) > > On Mon, Nov 13, 2017 at 10:33:39PM -0800, Shawn Landden wrote: >> Package: command-not-found >> Severity: wishlist >> >> I re-wrote command-not-found to get rid of the python dependancy, and >> to reduce the database size, as to reduce memory usage. >> >> https://github.com/shawnl/command-not-found >> >> I was preparing to upload it to mentors as command-not-found-ng > > I also rewrote it years ago, but using the same database format, > just in C. It was a lot faster. I don't understand the memory usage > bit - it should not matter how large the database is, it's memory > mapped, and not read into memory, as such memory usage should be > roughly constant. > > Questions/Comments for your approach: > > * Did you test your format on a slow HDD with caches dropped? It > must not be slower than the Python one (that one is way too slow > already) - I did, it seems to be faster (0.4 vs 0.68 seconds) > - I believe the database-based C rewrite was even much faster, > though. > * update-command-not-found should use apt-get indextargets > * You don't store components, hence you cannot tell people to enable > component. That's a very important use case for Ubuntu, where > not all components are enabled by default, but the database is > shipped in the package. > > You could just append /<component> to each package name I think, > and strip it away when displaying. I would love if we have a compact representation of mapping from name to list of bits of information where each bit can be a small structure with some data. Apart from components for ubuntu archive it could be used to store facts about snap packages, flatpaks, etc. I would try to avoid a simplistic command -> package mapping as that will force us to encode things into strings in an ad-hoc way. > * You should use getopt_long() to parse command-line options, and > support -h, --help :) > * pts_lbsearch belongs into usr/lib/..., not usr/share/... > > * You don't implement a closest matches function: > > $ command-not-found thunderbrd > No command 'thunderbrd' found, did you mean: > Command 'thunderbird' from package 'thunderbird' (main) > thunderbrd: command not found > $ ./command-not-found thunderbrd > thunderbrd: command not found > > This one is really important. People do make typos or misremember > command names, so the tool needs to be able to deal with that +1 on this, the function should be not too hard to implement in C. > Should be easy to implement though, although you might hav > * You need to Conflict with command-not-found and not Break AFAIUI Ideally, to ease the transition, you should do something about the python APIs. If yo can keep them (either as pure-python bindings or just as a compatible implementation) that would be a plus. If you want to drop them then please announce that and see if anything rdepends on it. > * You do have to Depend on apt-file, as that configures apt to download > the Contents files I didn't look at the details but I (hope) this is a build dependency and this will be processed somewhere on the archive side. > I think it's a worthwhile approach, and I can see it replacing > command-not-found if those tiny issues have been fixed. Then you > could also avoid the -ng moniker, and just take over the main > package (if Zygmunt does not mind), which also avoids a month > long NEW process :) Yes, though I'd like to participate as we're working on command-not-found improvements in snapd and would like to have something that fits Debian, Ubuntu as well as (eventually but not conflicting at least) Fedora and openSUSE (at least the snapd part). Best regards ZK -- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss