| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Anssi Hannula, fixes bug #52667
k1-1 provides k, but not k1-2
l-1 and l-2 requires k
m-1 requires k but not m-2
n requires m
User has l-1, m-1, n-1, k1-1.
There is only one upgrade path:
k1-1 -> k1-2
m-1 -> m-2
removal of l-1
When transaction is created with all of them (e.g. what --auto-select does
first), the path is resolved correctly.
However, when the upgrade is triggered with the upgrade of k1, and l is in RPM
db before n, resolving proceeds as follows:
1. k1 selected and old version rejected
2. l is promoted
3. m is promoted
4. l-2 is therefore selected
5. no packages are found for k (as k1-1 was rejected in step 1)
6. backtrack_selected calls resolve_rejected to reject the chain
7. rejection process rejects l, m, n
8. m-2 is selected because of step 3
End result: n is wrongly removed.
Therefore, when using --auto-select (with --split-length 1 --split-level 1 in
this small case, to force splitting) to trigger the upgrade, the early resolve
is done correctly, but the first splitted transaction ("rpms sorted by
dependencies" has k1 and m separately, so split is tried) tries to remove n and
URPM fallbacks to single big transaction.
In reverse, when using "urpmi k1" to trigger the upgrade, urpmi asks user
confirmation for n removal, but the transaction is created with both k1 and m
("rpms sorted by dependencies" has k1+m, so they are put in same transaction),
thus triggering the correct behaviour and n is not really removed after all,
even if user agreed to it.
Attached patch fixes this by switching backtrack_selected() to use
set_rejected_and_compute_diff_provides() for package removal instead of
resolve_rejected_(). The code already contained a comment indicating that
diff_provides code should be applied.
The patch introduces no regression in the urpmi and perl-URPM testsuites.
|
| |
|
|
|
|
| |
that was added in 3.31 (Anssi Hannula). In a simple mistake, %options was
not passed to backtrack_selected.
|
| |
|
|
| |
Patch from Anssi Hannula, fixes part of bug #52153
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Anssi Hannula, fixes bug #52460
When searching for possible promotions, _handle_diff_provides() allows
downgrade as well as upgrade.
However, downgrade is not currently supported, and will fail early in
_no_more_recent_installed_and_providing(), called from
resolve_requested__no_suggests_().
As no backtracking is done for early failures in this function (should it be?
dunno), the promotion gets forgotten and a failing transaction will occur.
Simple fix is to only allow upgrade before doing the promotion. Patch attached.
It introduces no regressions in urpmi or perl-URPM testsuite.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Anssi Hannula, fixes bug #52145
If package 'a' Conflicts on 'b', and user (or a dependency chain) tries to
install both at the same time, perl-URPM will only detect the conflict if
package 'a' gets selected first (this depends on hdlist order), as
_set_rejected_from is only called in one direction from _handle_conflicts and
it does not detect that a package it is about to reject_from is already
selected.
This bug currently causes a failure in urpmi handle-conflict-deps2 testcase.
This commit checks if avoided package is already selected, and unselects
current package in such a case
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Anssi Hannula, first step toward fixing bug #52145
If package 'a' Conflicts on 'b', and user (or a dependency chain) tries to
install both at the same time, perl-URPM will only detect the conflict if
package 'a' gets selected first (this depends on hdlist order), as
_set_rejected_from is only called in one direction from _handle_conflicts and
it does not detect that a package it is about to reject_from is already
selected.
This patch moves part of _handle_conflicts to _handle_conflicts_with_selected
to be called before dependencies get added, needed by next patch
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Anssi Hannula, fixes bug #52135
If package a has "Conflicts: x" and b has "Provides: x", installing both at the
same time creates a failing transaction (instead of producing the "cannot
install a (or b), continue?") as perl-URPM does not detect the conflict, as it
just checks the conflicts on the package name (it does the correct thing with
installed packages, though).
_handle_conflicts: call _set_rejected_from if any provides match the conflict,
instead of just package name
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch from Anssi Hannula, fixes bug #52105
lib64gcj9 has to be removed (conflicts), therefore so does libgcj9-src (x86_64)
that depends on it. Installed java-1.5.0-gcj-src depends on libgcj9-src, so
perl-URPM tries to promote the i586 libgcj9-src for it. However, strict_arch
check prohibits changing the arch, so it falls back to backtracking.
Backtracking finds libgcj9-src again and tries to select it; however, it drops
$dep->{psel} and $dep->{promote}, so when it fails again, perl-URPM does not
know java-1.5.0-gcj-src should also be removed due to the failed promotion.
This patch changes the code in backtrack_selected in two ways:
1) When a replacement package is found, keep {promote} and {psel} info, so that
when backtrack_selected is run the second time it correctly handles the failed
promotion.
2) When such a replacement fails as well and the deadlock protection is
triggered, do not switch to keep mode for the package that caused the promotion
(it would unselect all the packages involved in the update that caused the
promotion). Instead proceed to remove it as usual.
The patch introduces no failures on the urpmi testsuite.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Anssi Hannula, fixes bug #50666
removed/obsoleted levels are set in set_rejected() when a package is rejected
(i.e. removed) or a rejection reason is added. They keep track on whether the
package is removed and/or obsoleted.
When the package has both flags and one of the rejection reasons is removed by
_remove_rejected_from(), appropriate flags do not get removed.
The case I encountered: the package is set for removal when a package it
depends on fails upgrade due to unsatisfied dependency and has to be removed
(backtrack_selected => resolve_rejected, causing removed=1), and the package is
then promoted (causing obsoleted=1). However, the promotion fails due to the
same unsatisfied dependency and backtrack_selected =>
disable_selected_and_unrequested_dependencies => disable_selected =>
_remove_all_rejected_from => _remove_rejected_from gets called. This removes
the latter rejection reason, but leaves flags, including the now wrong
obsoleted=1. Thus the package is not explicitely removed as an obsoletion is
assumed, therefore failing the transaction.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This reverts the previous commit
only compute diff_provides when the package is newly rejected, in
set_rejected_and_compute_diff_provides
Try this incremental patch. It fixes
set_rejected_and_compute_diff_provides to
not compute diff_provides if package was already rejected (and thus the
dependencies properly handled already).
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Fixes bug #48100, patch from Anssi Hannula
Package A requires D and E.
Package B provides D and E.
Package C provides E.
If the require on E happens to be resolved first, then perl-URPM will
prompt the user, even though installing B is enough.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When installing a package which suggests an uninstalled package, urpmi
currently installs both packages without asking the user while it asks
when installing a package which requires an uninstalled package. This is
because we call resolve_requested__no_suggests to find which suggested
package to install, but this mark the package as requested as well (and
we don't ask for confirmation before installing a requested package).
This patch calls resolve_requested__no_suggests_ (with a trailing '_')
instead which is the same as resolve_requested__no_suggests but does not
mark the packages as requested.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes bug #48223, patch from Anssi Hannula
Currently, if _handle_diff_provides finds unsatisfied requires on an already
selected package, and cannot find any packages from the repo that satisfy
these, it calls resolve_rejected_ (or set_rejected_and_compute_diff_provides
after fix to bug #47803) (as it does when those unsatisfied requires are on an
installed package, which was always the case before r242656).
However, those should be called with installed packages only.
Attached patch makes _handle_diff_provides call
disable_selected_and_unrequested_dependencies and _set_rejected_from in case of
selected packages.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
conflict
Fixes bug #47803, patch from Anssi Hannula
Closer look at urpmi revealed it only does this if a provide X is
removed from
an upgraded package, not when a package providing X has to be removed.
i.e. this works:
A provides foo
B provides foo
C requires foo
Installed A,C.
A is upgraded and Provides:foo is dropped, B gets installed in order to
keep C.
But this won't:
A provides foo
A requires dep
B provides foo
C requires foo
D provides dep
Installed A,C,D.
D is upgraded and Provides:dep is dropped, A gets removed, C gets
removed.
|
| | |
|
| |
|
|
|
| |
- add some comment
|
| |
|
|
| |
a "requires", fixes bug #46874
|
| |
|
|
|
| |
- enhance a comment
|
| |
|
|
|
| |
but was not working if packages were coming from different repository)
|
| |
|
|
|
|
| |
superuser--priority-upgrade.t test case), and introduce
$state->{rejected_already_installed} instead
|
| | |
|
| |
|
|
|
| |
build_transaction_set()
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
but it in $state->{rejected} with flags {installed}
|
| |
|
|
|
| |
(to be used in urpmi 5.20)
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
code will then fix the unsatisfied require). fixes "big transaction"
(cf urpmi split-transactions--strict-require.t test_efgh())
this code was introduced long ago (*), the code has
changed quite a lot, and it's hard to tell for which reason it was introduced.
Maybe the check "obsoletes_overlap" replaces it for good?
(*) in "r11064 | fpons | 2002-06-13", search for "try if upgrading the package
will be satisfying all the requires"
|
| |
|
|
|
| |
selected_size_filesize() to compute the sum
|
| |
|
|
|
|
|
|
| |
(#30198)
nb: since build_transaction_set calls resolve_requested, it must use the same
options to select the same packages
|
| |
|
|
|
| |
installed (#29838)
|
| | |
|
| |
|
|
| |
(#17106)
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
(fixes #35718, ie auto-selecting with strict-arch)
(!! DANGEROUS CHANGE !!)
|
| | |
|
| | |
|
| |
|
|
|
| |
_find_required_package__sort() (since it's not really a sort)
|
| | |
|
| |
|
|
| |
_find_required_package__sort()
|
| | |
|
| | |
|
| | |
|
| | |
|
