Shouldn't be apt-get-centric

Thanks for your bugreport.

Out of interesst, what do you use? aptitude? dselect?

Cheer,s
 Michael

aptitude, thanks to it's lovely auto-removal handling.

apt-get also has autoremove:-

-----------------------------------------------------------
alan@tigger:~$ sudo apt-get install links2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libdirectfb-0.9-25 libsvga1
The following NEW packages will be installed
  libdirectfb-0.9-25 libsvga1 links2
0 upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/3220kB of archives.
After unpacking 5857kB of additional disk space will be used.
Do you want to continue [Y/n]?
Selecting previously deselected package libdirectfb-0.9-25.
(Reading database ... 23669 files and directories currently installed.)
Unpacking libdirectfb-0.9-25 (from .../libdirectfb-0.9-25_0.9.25.1-5ubuntu2_i386.deb) ...
Selecting previously deselected package libsvga1.
Unpacking libsvga1 (from .../libsvga1_1%3a1.4.3-24_i386.deb) ...
Selecting previously deselected package links2.
Unpacking links2 (from .../links2_2.1pre26-4build1_i386.deb) ...
Setting up libdirectfb-0.9-25 (0.9.25.1-5ubuntu2) ...

Setting up libsvga1 (1.4.3-24) ...

Setting up links2 (2.1pre26-4build1) ...

-----------------------------------------------------------
alan@tigger:~$ sudo apt-get autoremove links2
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
  libsvga1 libdirectfb-0.9-25
The following packages will be REMOVED
  libdirectfb-0.9-25 libsvga1 links2
0 upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
Need to get 0B of archives.
After unpacking 5857kB disk space will be freed.
Do you want to continue [Y/n]?
(Reading database ... 23778 files and directories currently installed.)
Removing links2 ...
Removing libdirectfb-0.9-25 ...
Removing libsvga1 ...

On Tue, 2007-03-20 at 11:30 +0000, Alan Pope wrote:
> apt-get also has autoremove:-
That's news to me, but my argument still stands, people might prefer
other package managers.
--
Bruce Cowan <email address hidden>

Implemented an extension that searches for ~/.command-not-found/install-package-cmd. If you put something like 'aptitude install' it will pick it up and display it instead of 'apt-get install'

apt-get's autoremove sucks, sorry. It wants to autoremove like half my system right now, and there's no way to tell it, "No, I _WANT_ to keep these packages!" Aptitude, however, is being very nice about it and not mentioning any packages right now. In fact, aptitude can actually autoremove old kernel images so my 54 MiB /boot partition doesn't max out with only 3 kernels every time.

Aptitude also has better dependency handling and can recover from errors when packages fail to install/configure (without leaving your system hosed).

I suggest that this bug be expanded to Ubuntu in general. Debian 4.0 (and probably 3.1) recommends usage of aptitude over apt-get in most situations (especially when it comes to dependencies).

Matt, maybe you should file a bug against apt-get rather than comment here where it wont necessarily get seen.

I had thought that (despite aptitude being horribly slow) the recommended command line package tool was aptitude and not apt-get.

If this is the case it seems strange that the command line magic in ubuntu points users to "apt-get install" instead of "aptitude install".

The next version that is not included in feisty has a perference option that allows you select either one.

I have heard this "aptitude is prefered" before but have never seen any official documentation to support it. I appreciate that some people prefer it, but that's personal preference not Ubuntu policy as far as I can see.

The official docs don't even mention aptitude:-

https://help.ubuntu.com/community/Repositories/CommandLine

Whilst aptitide is mentioned all over the wiki and help sites, that seems to be just where the editor of the page happens to use aptitude themselves, not for any particular development decision reason.

Debian recommends aptitude over apt-get [1].

I think that command-not-found should just say "install <package>" instead of saying the exact command to install the package.

[1] http://www.debian.org/doc/manuals/reference/ch-package.en.html#s-apt-commands

I strongly disagree about not telling the user exactly how to install a package. This is mostly intended for new users that cannot search package directory yet and are stuck looking for something they want to use.

Debian can replace the default value and recommend aptitude instead.

Reopening, since even on hardy, command-not-found still insists on apt-get (I think the argument that aptitude should be default if nothing else has been specified has some merit)

 $ cat ~/.command-not-found/install-package-cmd
 aptitude install

yet, nothing

Hmm apparently for some reason aptitude vs apt-get selection code is missing in Hardy

Zygmunt, are you sure there is such code? Still not working in Intrepid.

I don't see any such code anywhere, not even in the Jaunty source.

$ rgrep install-package-cmd command-not-found-0.2.31ubuntu2/
$

Zygmunt seems to be busy and not actively working on this. Reassigning back to nobody.

I'm sorry I don't really have time to get this fixed ATM (basically I don't do source uploads which means I cannot control how the code is fixed etc).

To put the story to an end:

1) Yes there *was* some support for this in my code (I wrote it back 3 ubuntu cycles from now)
2) I think the code was never released due to 0.2 -> 0.3 failed rewrite and multiple versions actually shipped by Ubuntu (which are now de facto latest version)
3) Yes there is no *released* version that supports this

I'd love to fix this but maintaining this package is a pain in the neck:
 * building the database requires tons of bandwidth or someone to constantly help you at canonical
 * python has some nasty issues that I didn't know of when I started - it's better to rewrite this in C
 * I have a full-time job and a family which kind of get in the way

Zygmunt, thank you for taking the time to reply. Your previous work is appreciated.

Excuse me if I'm being naive, but I took a brief look at the sources today (even hardwired aptitude into c-n-f instead of apt-get) and wouldn't it be just replacing the hardcoded strings that are present now with some variable that either holds "aptitude" or "apt-get"? The variable would have a sane default (I'd say aptitude), but a user-defined override in a config file would be honoured.

Am I overlooking something or did you have bigger things in mind to fix alongside?

No you're right - it's very easy to fix this. I added a configuration file (per user) that allows you to choose aptitude. Simple variable was not enough because I think with apt you need two programs and with aptitude you only needed one and I had some localization issues. I cannot remember exactly.

As for my whines - they are generally expressing why I'm not touching c-n-f for quite a while. They are not specific to this problem (except for the part that I didn't ever upload fixes to ubuntu myself and always needed help with that which does slow things down)

Two things:

 1. It would be cool if this could be globally configured, as well as per-user configured. Religious battles aside, I have a personal preference for aptitude, and would like to encourage users on systems I administer to use it.

 2. It would also be cool if I could replace "apt-get install" with an arbitrary string, instead of just choosing between apt-get and aptitude, as well as having config frobs for whether or not sudo is necessary. In particular, I could see wanting to transition to using PackageKit in the future, so ideally I should be able to tell unprivileged users to use "pkgcon install foo" instead of "sudo apt-get install foo"

Zygmunt, thank you for your continued support. Any chance we may see this in Lucid?

I think that depends on Lucid freeze time. A simple fix shoud do it.

Can you provide something for testing?

I will work on a lucid branch this evening. I'll post updates here

Branch is ready, I just need to publish this

Sorry, it's hard to aim on this lousy touchpad, the fix is not released jet, just commited

Zygmunt, I had a look at the bzr branch and I don't see anything. Can you give me a pointer where this is released?

> I have heard this "aptitude is prefered" before but have never seen any official documentation to support it.

From the dpkg man page:

"dpkg is a tool to install, build, remove and manage Debian packages. The primary and more user-friendly front-end for dpkg is aptitude(1)."

I agree with Evan that there should be some global configuration for this, but it seems to me that aptitude as a default is better than apt-get, and we're going to need a default either way.

As far as I know, this is still not fixed.

Please don't change the status on upstream project.

This was fixed in: lp:command-not-found/lucid revno 113 (http://bazaar.launchpad.net/~zkrynicki/command-not-found/lucid/revision/113) it just never got to ubuntu.

Zygmunt, I hope you are still following this ticket. You marked the upstream ticket as fix released. Did your code ever make it into an official upstream release? What version?

I suppose revision 113 that Zygmunt talked about is now https://bazaar.launchpad.net/~zyga/command-not-found/trunk/revision/113