2015-11-13 2:10 GMT+00:00 Vincent Lefevre <vinc...@vinc17.net>: > On 2015-11-12 21:57:33 +0000, Manuel A. Fernandez Montecelo wrote: >> In your example above, using hold also would not install v2 from >> testing, and when v4 appears, you notice and unhold, and all is well. >> What's the drawback of using Hold in your use-case? > > No, when a package is on hold, aptitude does not give any notice > when a new version arrives. That's why I don't like it.
So when you put packages on hold in testing, say "v1", and "v2" appears in unstable or testing, the packages don't appear in the bunch of "Upgradable" when there are newer versions? >> The candidate version (not the highest, but the candidate; e.g. the >> latest in unstable instead of the one in experimental) is shown in the >> right-most columns. Once it reaches a version that you are satisfied >> with, you unhold and it will be allowed to install. > > To know whether I am satisfied with some version, I need to know > whether there is a new version. Otherwise the package remains on > hold forever. Apart from appearing in "Upgradable", one can limit the view to "~U~ahold" (which is like upgradable but further limiting to only packages on hold; if the list of Upgradable is too long to check all), or one can check every now and then if the packages on hold have new versions in their package info screen (hopefully you don't have dozens of packages forbidden/hold). If one feels that Hold is too heavy handed and that forbidding a versions is a hassle because other versions appear all the time, one can simply not upgrade the package until it's good to upgrade. This is mosly what I do. They keep in the Upgradable set, so it's easy to keep track of them. It requires manual actions, but the proposed solutions also does require manual actions, to forbid versions again and again as they appear in repositories like unstable, if one is unsatisfied with many versions and want to forbid them all of the time. Checking whether they continue to be broken or not (reading BTS, changelogs, whatever) takes probably a bigger portion of time, though. >> If there is only one bad version that is known to misbehave, OK, one >> forbids that. >> >> If there are multiple versions that one wants to forbid, then there is >> something seriously wrong with the package (or something needed by the >> current versions that other versions don't provide), so one might as >> well use Hold until the situation clears up. > > But one can miss security fixes, which is really bad. It can, because there are many ways in which mixing different suites in your system and how you pin them can have undesired effects. Forbidding versions will cause the same or equivalent sets of problems, in the packages themselves and their reverse-depends. In fact, installing packages (without holding or forbidding at all) from experimental or from backports can also make you miss security fixes as well. For example, if somebody uploads "package-v2~rc1" to experimental and you install it, while versions v1 with fixes continue to arrive to unstable, you miss all of those (unless you keep checking for them and downgrade if necessary). Same with stable/security if you use packages backported with higher versions, or packages from testing or unstable. In particular, experimental can have broken packages for years without anybody bothering to remove those. All of these cases mostly happen if you upgrade to a version in testing/unstable/backports while using stable, or experimental if using unstable, because the security updates or more stable version arrives in the suite with lower versions, so getting the newest fixes implies checking by hand if new but "older/lower" versions arrive, and downgrading. All of this is in the terrain of "unsupported" and "you are on your own", though. Downgrading is something that you've been declaring as quite dangerous in other bug reports, and it is true that it's dangerous sometimes, so this should be taken into account before mixing suites and versions from different suites. Packaging tools will never know which repositories (esp. outside Debian) are supposed to contain the best up to date or higher priority for security upgrades, except in the sanctioned combinations to that effect (stable+security, for example), so the user should better know what s/he's up to when using unsupported suites. Cheers. -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
