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

[Keshav Kini]

On 09/17/2016 08:20 AM, Axel Beckert wrote:
> Manuel A. Fernandez Montecelo wrote:
>> 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.

I'm not sure what you mean by that, but just to clarify, the previous
appearance of any package that is not marked for upgrade (whether it is
upgradable or not) remains unchanged by this patch.  The patch *only*
affects the appearance of packages that are marked for upgrade.

It is true that it is now possible for a package not to be bold even
though it is installed -- in particular, this happens if the package is
installed and marked for upgrade and the upgrade is Debian-specific.  On
the other hand, it is still impossible for a package to be bold when it
is not installed.


Anyway, I generally agree with Manuel's concern that the meaning of the
bold attribute is being used to mean two different things.

Originally I wanted to just change the background color slightly, as he
suggested -- a lighter shade of blue for upstream upgrades.  But I found
that ncurses only supports 8 colors, and aptitude is already using all
of them.  However, setting the bold attribute achieved the goal of
brightening the background color, so that's why I used bold.

One way to brighten the background color without using the bold
attribute would be to wait for libncurses in Debian to switch over to
the ncurses 6.0 ABI, which provides 256-color support.  Then one could
freely choose a slightly lighter blue color as the background color
without using attributes like bold.

I don't know how far in the future that might be, though.  Bug #796835
seems to indicate that we'll move over to the new ABI after Debian 9 is
released, but if that's the case I don't really understand why the bug
was closed.  Maybe I haven't found the right bug number.

>> 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.

Yes, I don't mean to imply that Debian-specific changes are somehow less
important, but I still think it's an interesting distinction to make.
One difference is that when there is an upstream version bump, I need to
check the upstream package's own changelog to get a full picture of
what's new, since the Debian changelog will only say "new upstream
release" as a summary.

Thanks to both of you for your feedback!

-Keshav