[Aptitude-devel] Bug#837971: Bug#837971: aptitude: [PATCH] Distinguish Debian-specific and upstream upgrades

[Axel Beckert]

Control: tag -1 - patch.

Hi,

Manuel A. Fernandez Montecelo wrote:
> >Will probably have to try it so see how it feels, but in general I
> >like the idea. So thanks for having already included a patch!
> 
> Thanks for the suggestion and the patch.
> 
> My view on this request is not so positive, though.
> 
> Currently, the whole line is bold or normal depending if the package is
> installed or not.

Ok. The screenshot only showed packages already marked for upgrade. Of
course, there can't be non-installed packages being listed as to be
upgraded, so it doesn't matter there, so I didn't noticed that change
of semantics.

But so it seems to change the semantics for upgradable packages which
are not (yet) marked for upgrade.

Another thing which I didn't expect but which is shown by the
screenshot is that the bold flags seems to not only change the font
but also the background color, which is IMHO too much change. Hence
removing the tag patch for now.

> More in general, I don't think that the distinction between upstream
> upgrades and non-upstream upgrades is very interesting, and it can be
> misleading in some cases:
> 
> - Upgrading to libssl_1.0.0-2 from -1 might be much more urgent /
>  recommendable / whatever than upgrading fonts-liberation_2.0-1 from
>  -1.0-1; even if one is a whole new upstream release and the other just
>  a debian revision.
> 
> - Sometimes upstream changes can also be embedded in patches of debian
>  revisions (e.g. supporting a new device), and debian revisions
>  sometimes contain very relevant/important changes (e.g. enabling by
>  default a new media backend for a player), while there are upstream
>  releases that only contain changes for other OSs or use cases that
>  don't affect Debian or the user at all.

Sure, it can not replace reading the changelog. But it's nevertheless
a clear distinction in the kind of changes. Still thinking about a
less invasive visualisation which does not break existing semantics.

One potential way would be to handle that like security updates and
give new upstream versions a new foldable branch in the TUI. While I'd
use that, I think such a bold (sic!) distinction should be made
optional. (I also wonder if that could be established by pure
configuration changes. But then again IIRC the preview tab is not that
much configurable.)

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE