-
Notifications
You must be signed in to change notification settings - Fork 41
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
partial upgrades are confusing, and man page does not explain what upgrade means #101
Comments
Specifically, the man page does not explain that if for installed packages A and B, with B depending on A, that if A is in the repo and B is not, that will likely result with (old) B having an incorrect dependency A, which if the ABI is different will cause B to fail. It also doesn't give a hint of how a user might see if this is the case before upgrading. |
Partial upgrades via Partial upgrades via Issues around packages no longer being available in the repository will be dealt with in #100. |
upgrade is now defined, thanks. Consider a system "upgraded" if running "pkgin ug" would do nothing. If a system is not upgraded, then pkgin install is complicated. It might require a dependency which is not installed, which is ok. It might have a dependency which is, and the pattern might accept that, which is also ok. But it might require a newer version than what is installed. Because this is install, not upgrade, I expect (normaively) very strongly that new package may appear but that no existing package will be upgraded. But I lack confidence in this interpretation,, and would not be surprised (expected value) if pkgin upgraded some packages if it determined that was safe. So, maybe I should make a new ticket, Also, as an aside that is less than a bug, I find the ability to install when not upgraded but not to do partial upgrades inconsistent. Unless maybe install is really "add packages". |
23.8.0 fixes many issues around installing from an updated repository, and while it's still not recommended practise, it should now behave consistently. The behaviour is that the minimum amount of work required for the install operation is performed, however if installing the package requires an upgrade of an existing package, then we have no choice but to consider both the forward and reverse dependencies of that package, and in turn if any of those packages are upgraded, then we continue recursively. In practise this usually means that we end up with most of a "pkgin upgrade" being performed anyway, especially if the repository is much newer (my testing involved running "pkgin install" of highly-depended packages going from pkgsrc-2016Q1 to trunk). |
The idea that pkgin install will upgrade other things is totally not expected, and I see it as a bug. It's even worse if the user does not get "in order to install foo, we must upgrade bar, baz, bam, ok". After all, if the user wanted packages updated, they would run pkgin ug first. Basically I think that not being in a fully upgraded state is irregular and should not be encouraged at all, and either:
|
The user is shown a list of affected packages prior to accepting to continue, with the action to be taken for each. I don't agree that "pkgin install" should not work, I've spent a reasonable amount of effort over the past few weeks to ensure that it now works correctly for users who want this functionality for whatever reason. |
It should at least be clear - including when reading the manual -- that "pkgin install" is also an upgrade of between zero and all packages, depending on the dependency tree. As it reads now, it looks like it will always work and has no other consequences. I personally think partial upgrades are inadvisable, as they put your out of the zone of what people have tested (not the upgrade process, but that various expressed dependencies are accurate). I don't mind people having the option, but they should realize what they are getting into as they read what pkgin install does. |
When doing pkgin ug, and there are packages missing in the repo, pkgin just does a partial upgrade somehow. Given that the dependency graph is complicated, this seems unsound, and it's not at all clear what it's doing, how the user knows, what ought to happen, or where this is explained.
The text was updated successfully, but these errors were encountered: