2016-09-17 17:20 Axel Beckert:
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.
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.
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
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.
As another example, take Security Upgrades and normal Upgradable
packages for stable releases. In practice, non-security Upgrades can
also be Security upgrades or as critical for other reasons, so I think
that making them appear in different subtrees in aptitude is not very
helpful and, in fact, can be misleading if people don't consider them so
urgent/important as the ones coming from "security".
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
