[Aptitude-devel] Bug#729349: aptitude why should know about priorities

Manuel A. Fernandez Montecelo manuel.montezelo at gmail.com
Thu Dec 10 02:13:30 UTC 2015


Control: tags -1 + pending


Hi Paul,

2013-11-12 05:17 Paul Wise:
>Package: aptitude
>Version: 0.6.8.2-1.2
>Severity: wishlist
>
>When I do aptitude why on a priority standard package, aptitude doesn't
>know why the package is installed. It should know the obvious reason;
>that the Debian installer installed it because of the priority.
>
>pabs at chianamo ~ $ aptitude why apt-listchanges
>Unable to find a reason to install apt-listchanges.

I think that why/why-not were created mainly with the purpose of
providing succint explanations, quick and to the point, and mainly
focused on dependencies.

I agree though that "Unable to find a reason to install apt-listchanges"
is suboptimal, and can cause error of interpretation, and in a way by
focusing only on dependencies doesn't honour the name of the command
("why is this installed?").

So I changed it a bit to do this instead:

  $ aptitude why apt-listchanges
  apt-listchanges is manually installed, current version 2.85.14, priority standard
  No dependencies require to install apt-listchanges
  
  $ aptitude why-not apt-listchanges
  apt-listchanges is manually installed, current version 2.85.14, priority standard
  No dependencies require to remove apt-listchanges
  
  $ aptitude why testdisk
  testdisk is manually installed, current version 6.14-3+b4, priority optional
  The candidate version 6.14-3+b5 has priority optional
  No dependencies require to install testdisk
  
  $ aptitude why-not testdisk
  testdisk is manually installed, current version 6.14-3+b4, priority optional
  The candidate version 6.14-3+b5 has priority optional
  No dependencies require to remove testdisk


The changes are:

- I changed the message, so it doesn't mention "unable to find a reason"
  and instead "no dependencies require X".

- Priority included, as you suggested

- I thought that including information about being manually installed is
  quite a reasonable reason to explain "why is this installed"

- In different parts of aptitude the same functions are used for current
  versions and sometimes for candidate versions, so I just included a
  note about candidates just in case.  E.g. if the init system changes
  of priority in different Debian releases, or in testing from one day
  to the next, candidate is different between upgrades, and the user
  might wonder why aptitude wants to installed this newfangled thing...

Cons:

- It's not as succint as before, so I am not sure if there will be
  places where less information will be desired... "less is more"

- Due to the structure of the code paths, when it finds dependency
  reasons it doesn't print the new added information.  But then again,
  deps are enough reason to explain why it's installed or broken, I
  guess; and if we don't change that there is less chance of
  breakages/complaints because of Con #1.


At the moment I think that the main concern is addressed, so marking as
+pending.


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>



More information about the Aptitude-devel mailing list