tech-pkg archive

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

Re: Proposed fix for long-standing +CONTENTS bug



* On 2020-04-22 at 11:11 BST, Jonathan Perkin wrote:

> * On 2020-04-22 at 08:10 BST, Jonathan Perkin wrote:
> 
> > * On 2020-04-22 at 02:21 BST, David H. Gutteridge wrote:
> > 
> > > In any case, running "pkg_add -DU" directly on the newer versions of the
> > > binary packages still results in the same outcome:
> > > 
> > > # cat /var/db/pkg/vim-share-8.1.2200/+REQUIRED_BY
> > > vim-gtk2-8.1.2200
> > > # pkg_add -DU vim-share-8.2.0303.tgz vim-gtk2-8.2.0303nb3.tgz
> > > # cat /var/db/pkg/vim-share-8.2.0303/+REQUIRED_BY
> > > vim-gtk2-8.1.2200
> > > vim-gtk2-8.2.0303nb3
> > 
> > Ok, can you upload all of the packages in question somewhere for me to
> > look at?  Both the old and new.
> 
> Never mind, I managed to reproduce this locally testing a 2019Q4 to
> trunk upgrade.  Note that if you only run
> 
>   $ pkg_add -DU vim-gtk2-8.2.0303nb3.tgz
> 
> then it's fine.  Still, will investigate, thanks.

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.

  - 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.

The fix for "<>" patterns is relatively easy because we know that
everything proceeding it is a PKGNAME, but "{}" can be used anywhere.

Doing something like trying to match for the non-PKGNAME part of a
pattern feels like it could be pretty fragile.  For now my best idea
is for pkg_add to re-arrange its command line arguments to ensure that
packages are upgraded in dependency order, as either putting vim-share
last or removing it completely as I mentioned will avoid the problem,
but if anyone has any better ideas...

-- 
Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com


Home | Main Index | Thread Index | Old Index