tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg_rr and builtins

David Holland <> 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

Home | Main Index | Thread Index | Old Index