* On 2023-08-23 at 13:53 BST, Greg Troxel wrote:
Manuel Bouyer <bouyer%antioche.eu.org@localhost> writes:It may be new behavior; in the past I did run into an installed package that was not in the new repository (e.g. because it didn't build and I didn't notice). In this case, pkgin would just ignore it and I ended up with a non-working binarie (because shared libs of dependancies got bumped).jperkin has been working away making pkgin better. Bug reports help, so it would be good to try this out.
FWIW this is still the current behaviour. The thing to consider here is that the pkgdb does not record where a package was installed from, and so there's currently no way to distinguish between a package installed from a remote repository (where you would want to be notified that an update is missing), and one that was e.g. built locally and installed manually using pkg_add (where you would not).
There are some options to enhance the pkgdb in this regard, e.g. a new +INSTALLED_INFO variable that records the repository, but that throws up further questions like how do you accurately track that a repository URL switch from e.g. 2023Q2 to 2023Q3 should be considered as the same source repository?
An incomplete alternative approach, assuming they are recorded correctly (which may not be the case for any self-built packages), is to check all of the REQUIRES for installed packages and their proposed updates against the incoming PROVIDES to look for any missing dependencies. Of course this only takes into account shared library dependencies, and wouldn't help in the case where there is a dependency on a particular binary which is either removed or renamed.
This will take some thinking through before we arrive at a solution that improves the current state, so I'm happy for this to be moved over to a pkgin issue for further discussion.
-- Jonathan Perkin - mnx.io - pkgsrc.smartos.org Open Source Complete Cloud www.tritondatacenter.com