"upgrade" does not warn about missing packages in repo about pkgin

[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