"upgrade" does not warn about missing packages in repo

[gdt]

When doing pkgin upgrade, it can be the case that there aren't repo packages for some packages that are installed. The list of installed packages missing from the repo should be printed out clearly so that the user can decide to stop.

Arguably, packages are that are not keepable and are not dependencies in the target state should be listed separately, and perhaps pkgin should offer to remove them as part of the upgrade, as a question "Remove non-keepable packages that are both not in the repo and not needed after upgrade after the upgrade?". Or maybe that should be default, but that seems a bit scary.

[jperkin]

The fundamental problem here is that it is entirely legitimate for the user to have self-built packages installed on their system, whether from wip or elsewhere, and there is no way to distinguish those accurately from those that are installed from the remote repository.

Certainly nagging the user every time they perform pkgin upgrade that all of their additional packages could be affected isn't a great user experience.

One thing I will look into is whether we can perform a DEPENDS and REQUIRES check after install/upgrade, either via a new pkgin check command or automatically after install operations.

[gdt]

That makes sense about self-built. Actually I self build entirely on one machine, and then use that to manage elsewhere. But sometimes for various reasons a binary package isn't in the repo and should be. Personally I feel that if you are using pkgin you should drink the binary package koolaid and generate a pkg_summary for your locally-built packages and add it as a repo.

I see the point about nagging not being great, but an explicit pre-flight check that can be requested seems like it would help. Sort of "if I did pkgin fug, then are there any packages that are wanted but aren't here".

It would be nice to be able to predict if the upgrade is going to be ok, or if missing packages will cause trouble. I think this might be the pre-flight check above, and it might be less. Having a missing package is sort of ok if everything that depends on it is ok with the installed version.

And, sometimes I've seen: "foo is not in repo, proceed anyway?" only to create foo and then get warned about bar.

I will have a fresh look after the update; I get it that much of this is likely better.

[gdt]

Some concrete suggestions to make progress on a hard problem:

If an installed package is eligible for upgrade because the repository(ies) have a newer version, then if any dependency of that package is missing, print a warning/are-you-sure.

If a warning is printed, collect the entire list of things to be warned about. Avoid the pattern of complaining about A, user fixes A, complain about B, if it was knowable at A-complaint time that B was also an issue.

If an installed package is missing from the repository, and any dependency of that package would be upgraded, then check those for being allowable with the installed package. warn/are-you-sure if not ok