Bug#837971: [Aptitude-devel] Bug#837971: aptitude: [PATCH] Distinguish Debian-specific and upstream upgrades
2016-09-17 18:21 GMT+02:00 Keshav Kini : >> >> 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 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). > (which means I should have edited > whatever generates this documentation too... oops). Yeah, probably :) -- Manuel A. Fernandez Montecelo
Bug#837971: [Aptitude-devel] Bug#837971: aptitude: [PATCH] Distinguish Debian-specific and upstream upgrades
Hi, Keshav Kini wrote: > 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. 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). > 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. 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 -- ,''`. | Axel Beckert , 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
Bug#837971: [Aptitude-devel] Bug#837971: aptitude: [PATCH] Distinguish Debian-specific and upstream upgrades
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
Bug#837971: [Aptitude-devel] Bug#837971: aptitude: [PATCH] Distinguish Debian-specific and upstream upgrades
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
Bug#837971: [Aptitude-devel] Bug#837971: aptitude: [PATCH] Distinguish Debian-specific and upstream upgrades
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
Bug#837971: [Aptitude-devel] Bug#837971: aptitude: [PATCH] Distinguish Debian-specific and upstream upgrades
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 , 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
Bug#837971: [Aptitude-devel] Bug#837971: aptitude: [PATCH] Distinguish Debian-specific and upstream upgrades
Hi, 2016-09-16 13:47 Axel Beckert: Hi Keshav, Keshav Kini wrote: 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. 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! 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. -- Manuel A. Fernandez Montecelo
Bug#837971: [Aptitude-devel] Bug#837971: aptitude: [PATCH] Distinguish Debian-specific and upstream upgrades
On 09/16/2016 04:47 AM, Axel Beckert 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! 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. -Keshav
Bug#837971: [Aptitude-devel] Bug#837971: aptitude: [PATCH] Distinguish Debian-specific and upstream upgrades
Hi Keshav, Keshav Kini wrote: > 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. 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 -- ,''`. | Axel Beckert , 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
