Dear Maintainer,

When upgrading packages, aptitude users might like to know whether each
upgrade represents a newer upstream version of the package, or is merely
a Debian-specific change.  This can be determined by comparing the
current and candidate versions in the rightmost two columns of the
package listing, but I thought it might be easier to see at a glance if
these two kinds of upgrades were colored differently in the UI.

The attached patch (directly importable into git) makes upgrades that
represent a newer upstream version appear in bold, while upgrades that
represent a Debian revision bump appear as before.

Thanks,
    Keshav

Oops, looks like I accidentally attached the patch both as a MIME
attachment and inline.  Sorry about that -- they're the same patch.

Hi Keshav,

Keshav Kini wrote:

Interesting ideas (both, separating upstream from packaging changes as
well as using the bold attribute for highlighting).

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!

		Regards, Axel

Sure, my pleasure :)  It took a little poking around to figure out how
to do it but the patch ended up only being a few lines, thankfully.

I'm attaching a screenshot of how this looks in xterm with a bunch of
upgrades selected, for reference.

Hi,

2016-09-16 13:47 Axel Beckert:

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.  Given the coarse granularity allowed in terminals
with a limited number of colours or attributes, I am not sure that this
distinction is worthy enough to be warranted the "boldness" attribute
(rather than e.g. a different shade of "green" in a GUI application).

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.


So in summary, it can be useful for some cases (e.g. some specific
packages), but I don't think that the distinction between upsteam
versions and debian versions is very useful in a general case (for most
people and for most packages), so I'm not very keen on changing things
(specially if they imply visual changes) to the defaults that then are
problematic to reverse unless there are very clear advantages, which I
do not see in this case.


Cheers.

Hi,

Manuel A. Fernandez Montecelo wrote:

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.

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

2016-09-17 17:20 Axel Beckert:

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

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.

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.

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!

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.

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

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!

Hi,

Keshav Kini wrote:

Interesting. I assume that cwidget needs to gain support for that
first (unless it's that transparent for such things, which I don't
expect).

You've found the right bug. And as I understand it, it's closed
because it's considered done. Not sure where you've read that the
transition should be _after_ Debian 9 is released. I read it as if the
plan was to transition _before_ the freeze for Debian 9 is started.
And hence it looks perfectly fine to me that the bug is marked as
done.

		Regards, Axel

2016-09-17 18:21 GMT+02:00 Keshav Kini <keshav.kini@gmail.com>:

Yes, I think that without your new style wouldn't have been possible to do it.

I meant that I don't know if many people will be bothered to change
the defaults, since I never see this kind of options tweaked in
configs sent to bug reports, or complaints about much more big broken
things like the themes (so I was tempted to scrap theme support
altogether).

Yeah, probably :)

Hello Customer

We are pleased to inform you that your account renewal has been
successfully processed and is now complete. The necessary updates have been
applied, and your payment has been confirmed. Please see the confirmation
details below for your reference.

If you have any questions Call us

Thank you for choosing our services.

Thank you

Hello User @FSTA-5287

VACFRA56498754