If I have forbidden a package version in testing, and I see in unstable a new version with the bug not fixed, I cannot forbid that new one: if I do, the version in testing is not forbidden any more and will likely get installed. Thus I have to wait until it gets migrated and rely on me noticing at that time...
Control: found -1 0.6.11-1
Same problem. IMHO, aptitude should forbid all versions up to the
forbidden version, not just the forbidden version. This would match
a bit more the description, i.e. only newer versions will be
automatically installed.
"F": Forbid a package from being automatically upgraded to ▒
a particular version; newer versions will be automatically ▒
installed. ▒
BTW, it seems that when I hit 'U', the forbidden packages are not
selected as to be upgraded yet (they are still in white). The problem
can be seen only after dependency/conflict resolution.
Hi Yann,
2011-09-18 19:16 Yann Dirson:
This matches the intended use of the feature and documentation:
"Forbid a package from being upgraded to a particular version. This
will prevent aptitude from automatically upgrading to this version,
but will allow automatic upgrades to future versions."
Even if this worked for multiple versions, if you are unsure in which
version the package is going to fix a problem, 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).
In general, trying to extend Forbids to eat into the terrain of Holds
and create further overlapping between them is not good design, so I am
going to close this bug report.
Cheers.
Control: reopen -1 I am sure concerning which version*s* to forbid. 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.
IMHO, it is sufficient that aptitude forbids the selected version and all the *previous* versions. Said otherwise, aptitude should do a > test on the versions, instead of a != test. It is very unlikely that users want to forbid version X only and still allow to upgrade or downgrade automatically to a *previous* version.
severity 642030 wishlist tags 642030 + wontfix stop 2015-11-12 13:37 GMT+00:00 Vincent Lefevre <vincent@vinc17.net>: 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.
appears in unstable and is buggy. One does "F" on it. Then v2 moves to testing. Later, v3 appears in unstable and is still buggy. One does "F" on it. But now, aptitude wants to install v2 from testing! aptitude just shows v9-2. The only way to see v8-2 is to use "F", ask for an upgrade, and the user will see v8-2 only if it can be installed (i.e. it isn't blocked by a dependency or a conflict). Ditto, aptitude only shows the latest version, so that only v9-2+exp1 is visible. "F" does not hide older versions. They are already hidden by default. But with Hold, one cannot see when a new version is available. No, this is not visible with the curses interface. ? We, I only use the curses interface. Same problem. So, perhaps a solution would be to be able to have really several forbidden versions in /var/lib/aptitude/pkgstates: if a user forbids v2, them forbids v3 when it appears, then v2 should still be marked as a forbidden version.
2015-11-12 15:49 GMT+00:00 Vincent Lefevre <vincent@vinc17.net>:
My example was bad, all versions in testing come through unstable
first anyway, so there should be no cases like the above.
My example would work better if we consider unstable+experimental, or
stable+security+backports + testing (for the occasional package), the
packages can "arrive" independently with different versions in
different suites.
If forbidding versions ignores all versions prior to the one ignored,
forbidding the one in experimental (first case) or testing (second
case) will make aptitude ignore all new versions arriving in unstable
(first case) or stable+security+backports, which is the side-effect
that I don't like, compared to the current implementation.
The hypotetical implementation of F-ignoring-older-than would behave
exactly the same as "put the package on hold but remove it once a
package with version >VV arrives". That's equivalent to "hold"
(except the manual re-enablement), and that's why I was suggesting it
as an alternative solution to the original report.
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?
My bad. With "visible" I meant mostly "aptitude takes it into account
for resolving", it shows in dependency resolutions and so on.
For example, I had forbidden the versions of LibreOffice in
experimental, and the resolver still allows me to upgrade to the newer
versions of LibreOffice in unstable when they arrive (the packages
show up in "Upgradable", and the version arriving in unstable is
shown).
With the behaviour that you propose, it would be exactly like Hold,
and if I forbid LibreOffice with a higher version in experimental I
would not be able to upgrade to the newer version of LibreOffice in
unstable, and I might have to withhold upgrading other packages
because of this. With the current implementation of F, this is
possible, and it is an important use case.
So if we change the current implementation of F for the new, we would
lose important use cases explained before, while gaining basically
nothing, in my view.
Nope, it shows the candidate version in the right-most column (e.g.
the latest in unstable instead of the most recent in experimental,
unless experimental is pinned higher).
With the provision of "hiding" == "ignoring for all practical
purposes", in the 3 examples above, F (with "ignore older than") and H
would behave in the same way (except the automatic unhold) and would
ignore ("hide") all older version, while the current implementation of
F does only ignore a specific version.
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.
list of packages as "upgradable", it shows the candidate version in
the right-most column (as I explained above), and all the versions are
listed in the package info screen.
If one considers the bigger picture, forbidding versions or marking on
hold should be exceptional measures, not something that one does all
of the time.
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. It is almost equivalent
to forbid-version with multiple versions, and has no serious drawbacks
(except the need for manual Unhold), and if the current "safe" package
stays in the system a bit longer than strictly necessary (because the
user does not notice that it's in the "Upgradable" packages), there is
no big harm.
Cheers.
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. [...] But then, you don't need to forbid versions in experimental. 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. No, you didn't explain anything. How can I know that the version is *new*??? I do this many times because packages have major bugs. But one can miss security fixes, which is really bad.
2015-11-13 2:10 GMT+00:00 Vincent Lefevre <vincent@vinc17.net>: 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? 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. 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.
They still appear on hold, and I cannot know whether there is a new version or not. But how can I know whether the version is new? I have never seen the equivalent of New/Unread markers used for e-mail. Well, with all the packages forbidden/hold on my 4 Debian machines, I do. :) For such packages with often new versions, this is where Hold can be used. The issue is for packages without often new versions, but with at least two candidates for an upgrade. I use neither experimental[*] nor backports. I don't use unofficial repositories like Debian multimedia either. [*] Well, only in some exceptional cases to test bug fixes, but then I track what happens.
2015-11-13 11:31 GMT+00:00 Vincent Lefevre <vincent@vinc17.net>: Assuming that the version is not the "candidate version" already visible in the right-most column (which in many/most examples given so far, it should be), I can only suggest manual review by looking into the package info screen. Testing and unstable are also for people who are OK with getting their hands dirty and track what happens when it is needed to, more so when mixing versions of both. The recent turmoil with the GCC-5 transition is a recent enough proof of that. When packages are on hold/forbidden/not upgraded it is also an unusual condition, so you have to keep track of what happens. Simply having the packages already in the Upgradable set or on Hold (or Forbid) is a highlight and constant reminder that you have to keep track of them to bring them out of that state. Cheers.
I don't want to do a manual review each time I upgrade the system. Things should be automatic. Moreover a manual review won't solve the problem here because the package info screen doesn't say whether the version is new or not. There could be a new feature, which would be "Hold until new version" (which corresponds to what I suggested for Forbid, but here as it would be a new feature, this won't change the existing behavior), or some marker for packages on hold with a new version, so that the user could check whether some bug is fixed then either confirm the hold or upgrade the package, for instance. But this should remain exceptional and not be the normal behavior. No, this is not unusual. This happens frequently... because packages have annoying bugs/regressions.