David Holland <dholland-pkgtech%netbsd.org@localhost> writes: > As discovered in PR 48481, if you have a pkgsrc version of a package > installed and updates to base cause the builtin version to become > eligible for use, pkg_rr doesn't notice. > > It seems like it would be good to offer the option to switch back to > the builtin version, especially since in many cases the builtin > version has been replaced with the pkgsrc version automatically and > more-or-less silently during an earlier update. > > I don't know if this is even remotely possible, though. Anyone? I think there are two sub-issues to what you suggest: 1) when rebuilding a package, use the builtin. I think this will happen, or if not it's a bug in "make package" rather than in pkg_rr. 2) how to mark a package dirty in this case. We can think of a dependency on something that can be builtin or a package as logically a dependency on a meta-package that selects one or the other (like ghostscript), and then when one replaces the meta-package to switch, the depending package will be unsafe_depends. (This could be extended to track shlib majors in builtin libraries, and eventually we arrive at syspkgs from a different angle.) So I think what's needed, practically, is something like: make show-depends will point out builtin things that are depended on there's some way to iterate over packages and compare new dependencies with built dependencies, and mark packages unsafe_depends if they don't match. I think this is really a bug in dependency tracking where we don't do anything when the base system is updated, more than a bug in updating.
Attachment:
pgpYSsv7uz5UC.pgp
Description: PGP signature