Re: Proposed fix for long-standing +CONTENTS bug

[Greg Troxel <gdt%lexort.com@localhost>]

Jonathan Perkin <jperkin%joyent.com@localhost> writes:

> Ok, so it's due to {} matching, and this opens up a bit of a can of
> worms.  I'm honestly not sure of a decent way to fix this, there are
> so many complicated types of dependency when we support that, I don't
> think there's a possible way to go back and match things up once we've
> explicitly told the package database that we're breaking things
> because we (allegedly) know what we're doing.
>
> To clarify, here's the problem:
>
>   - vim-gtk2 has an explicit dependency on "vim-share-8.1.2200{,nb*}",
>     stored in its +CONTENTS file as a @pkgdep.
>
>   - We upgrade vim-share to vim-share-8.2.0303, and inform pkg_install
>     via -DU that it's fine to completely ignore all of the dependency
>     checks, and to leave the pkgdb in an inconsistent state.

pkgdb inconsistent can mean two things.  I think one is ok and one we
need to avoid

  Having a line in +REQUIRED_BY that corresponds to a package that does
  not exist is a database constraints violation and should never
  happen.  I think fixing that is the real issue.

  If one uses -D, then there can be packages installed (that depend on
  the one just updated) whose dependencies are not satisfied.

>   - Now we come to upgrade vim-gtk2, and of course the hardcoded
>     "vim-share-8.1.2200{,nb*}" no longer matches any installed
>     packages, so vim-gtk2's entry is never removed from vim-share's
>     +REQUIRED_BY, resulting in the duplicate entry.

I wonder if stepping back and pivoting would help here.

To use the example, when vim-gtk2 is upgraded, the thing to do is find
all packages that have a +REQUIRED_BY of vim-gtk2, and (assuming that is
vim-share) to either

  remove the entry, if we want to leave vim-share with a dangling
  dependency

  change the entry to the new vim-gtk2, if we want to leave it with a
  recorded dependency (which is true) on a version that isn't right

I can see this might be a bit more cpu time, but it doesn't seem hard,
and it seems like the right thing always, and the current approach is an
optimization that isn't working when there are these mismatches.

Does this  seem 1) sensible and 2) feasible?