Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

pkg upgrade may wrongly skip a package annotated with repository tag #631

Closed
avg-I opened this issue Nov 1, 2013 · 2 comments
Closed

pkg upgrade may wrongly skip a package annotated with repository tag #631

avg-I opened this issue Nov 1, 2013 · 2 comments

Comments

@avg-I
Copy link
Member

avg-I commented Nov 1, 2013

Suppose we have repo1 and repo2 configured as repositories.
Then there is a package 'bar' with origin 'foo/bar'.
The package is installed, it is annotated with repo2.
The package is also outdated. Let's say its version is 1.1 while both repo1 and repo2 have version 1.2.

jobs_solve_upgrade would call get_remote_pkg with foo/bar as a pattern.
pkgdb_rquery would return an iterator over both remote package (one in each repository). Let's presume that the package from repo1 would be the first.
newer_than_local_pkg would return false for the package from repo1 because the repository name would not match the annotation on the locally installed package. As a result, the remote package from repo1 would be added to j->seen hash table.
On the next iteration, we would work on the package from repo2. A lookup in j->seen, which is done by origin, would find the previously seen package from repo1. Thus the code flow would go into the following block with 'seen' set to true:

if (p1 != NULL) {
        pkg_get(p1, PKG_VERSION, &buf1);
        pkg_get(p, PKG_VERSION, &buf2);
        p->direct = root;
        if (seen) {
                if (pkg_version_cmp(buf1, buf2) >= 0)
                        continue;
        } else {
                if (pkg_version_cmp(buf1, buf2) == 1)
                        continue;
                HASH_DEL(j->bulk, p1);
                pkg_free(p1);
        }
}

Because the packages from repo1 and repo2 have exactly the same version the repo2 package would simply be skipped.

It seems that the quoted code does not account for the fact that p1 might have been previously skipped for reasons other than unsatisfactory version.

@bapt
Copy link
Member

bapt commented Nov 29, 2013

This will be totally reworked by syncing the code from the sat solver aka gsoc 2013

@bapt
Copy link
Member

bapt commented Jan 15, 2015

Somehow fixed with CONSERVATIVE_UPGRADE=yes in pkg.conf

@bapt bapt closed this as completed Jan 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants