severity 642030 wishlist tags 642030 + wontfix stop
2015-11-12 13:37 GMT+00:00 Vincent Lefevre <[email protected]>: > Control: reopen -1 > > On 2015-11-12 11:59:15 +0000, Manuel A. Fernandez Montecelo wrote: >> Even if this worked for multiple versions, if you are unsure in which >> version the package is going to fix a problem, > > I am sure concerning which version*s* to forbid. > >> it is more practical to use the Hold feature until you verify that >> it is fixed and safe to install, rather than to keep adding F >> versions every time that a new version pops up in the repositories >> (or failing to do so and be installed to a version that you don't >> want). > > I want to be able to upgrade to future versions (actually be aware > of them, which is what "F" does). So, "Hold" is not OK here. > > Remember that users can track both testing and unstable, and aptitude > does not always try to install the latest version. The problem I had > is that when I did "F" on the unstable version, aptitude then wanted > to upgrade to the testing version (i.e. en earlier version), which is > wrong. In the general case, if one is using v9-1 from unstable, v9-2 appears in unstable and v8-2 appears in testing and aptitude allows to forbid both, until it is actually released, one still doesn't know if the problem is going to be fixed in v8-3 and v9-3 (or any other future version that could pop up in the repositories at any point), so one has to keep constantly forbidding versions as they appear. If aptitude ignores forbidden versions "smaller" than a given version number, as you request, there are other sets of problems. Similar to the example above, if one uses v8-1 from testing, v9-2 appears in unstable with a problem and forbids that one, and then v8-2 appears fixing an important data corruption problem, that version would be ignored potentially for months, until >v9-2 appears in one of the used repositories. Considering other suites and not only testing and unstable, there could be v9-2+exp1 appearing soon, not fixing the issue that concerns the person but with other dangerous/disruptive changes that it is offered (e.g. depending on a broken version of libimportant), and v9.2~backport1 could actually fixes the issue and one would like to install (but ~backport1 makes it to be "smaller" than the given version, so it would not show). If one uses testing+unstable things usually go forward, but there are still oddities as this case that you mention. But there are also many other users of stable, backports and testing (or security upgrades), and probably more people using stable+backports+testing that people using testing+unstable, so hiding older versions is not such a good idea in those scenarios. tl;dr: relying on which version number is higher to presuppose things is not very foolproof, especially if one mixes versions and uses suites in flux like testing and unstable. On the other hand, one can use Hold, and Unholding only after one verifies that a new version was released and is OK to install. If the package that it's on hold is safe to use, keeping in the system even when there are upgrades around, is no a big problem. There are multiple ways to verify if new versions were released -- curses interface, command line patterns, paying attention to the number of not upgraded packages in the command line mode (does not work if one holds package almost all of the time, but still), or passing "-v" in future releases (see #553577) to list the number of packages that are not upgraded, in command line operations. Independently of that, I think that change the behaviour of this long stablished feature that can potentially hide security or backports is not good, and blurring more the lines between forbid-version and hold is not good design, and that's presumably why this hasn't been implemented by previous developers, so marking it as +wontfix. Cheers. -- Manuel A. Fernandez Montecelo <[email protected]> _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
