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

[Keshav Kini]

On 09/17/2016 09:08 AM, Manuel A. Fernandez Montecelo wrote:
> Dunno, maybe your experience is different or there are good examples,
> but from the Debian "insiders" side communicating with users, I think
> that marking the upgrades differently (specially bold/non-bold) as if
> some kind of upgrades might be more advisable / urgent / beefy /
> whatever than others is not an useful distinction to make, specially
> having into account that many of the upgrades break the general rules /
> expectations.
>
> For example, I don't remember any breakage with new upstream versions of
> bash (or indeed, I cannot remember any news-worthy changes either in
> most of the classic tools!), but on the other hand there are subtle --or
> not so subtle-- breakages if a version is compiled against new GCC
> versions even in binNMU releases without source changes (happened with
> the big C++ ABI break of GCC-5, also with GCC-6 and some notable cases
> like chromium).
> 
> Also, for me any libssl or chromium change (upstream or not) is
> significant: any libssl change is more often than not related to
> important/urgent security issues, whether upstream or Debian changes;
> and changes in chromium 53.0.2785.113-1 or debian revisions which fix
> the crashes with GCC-6 miscompilations are as likely to be significant
> as a full major version bump to 54.0.1241.123-1.
> 
> So in summary, even if we made the distinction /possible/ to change, I
> wouldn't make it different by default.

I see your point.  Showing Debian-specific upgrades differently from
upstream ones might certainly give some users the wrong impression about
Debian-specific upgrades being more or less important.

I guess it might be possible to carefully choose slightly different
colors so that neither one of them looks obviously "more important" or
"better" etc., to try to ameliorate this... but probably the better
solution is to make the distinction optional and turned off by default,
as you suggested.

> But anyway, things like these are possible for years with themes, which
> are broken also for many years (if they ever worked), and nobody
> complained about the broken support for years so I tend to think that
> people don't care too much about these visual tweaks.
> 
> http://aptitude.alioth.debian.org/doc/en/ch02s05s03.html

I'm not sure if this is what you meant, but I don't think the particular
UI change implemented by this patch is possible to implement using
themes, since I had to add a new style (which means I should have edited
whatever generates this documentation too... oops).

>> 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.)
> 
> Since I don't think that the distinction is very useful to make, I think
> that changing the trees for this reason wouldn't be very worthy either.

I probably wouldn't use a tree-based version of this either -- I found
it to be the most useful in the Preview pane, where there are no trees.

Thanks again for your feedback!

-Keshav