tech-pkg archive

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

Re: pkgdb corruption (was: Re: osabi in -current in some difficulty?)



On Fri, 15 Mar 2019 at 17:06:28 +0100, Benny Siegert wrote:
> I have seen this quite a bit too, often on vime-share like you. In
> this case, it might be a consequence of "make replace" on vim-share. I
> am thinking that the replacement (pkg_add -U IIRC) is buggy.
> 
> On Fri, Mar 15, 2019 at 4:49 PM David Holland <dholland-tech%netbsd.org@localhost> wrote:
> >
> > Greg Troxel <gdt%lexort.com@localhost> wrote:
> >  > In this case, you have a corrupt database.   I have some notes about
> >  > this to dig through about why this happens.
> >
> > Lately it has been happening to me somewhere on nearly every build
> > run.
> >
> > Checking the package databases on a couple machines shows multiple
> > examples, e.g.:
> >
> >    % pkg_info -R vim-share
> >    Information for vim-share-8.1.0551:
> >
> >    Required by:
> >    vim-8.1.0390
> >    vim-8.1.0551
> >
> > and
> >
> >    % pkg_info -R boost-libs
> >    Information for boost-libs-1.68.0:
> >
> >    Required by:
> >    libcdr-0.1.4nb6
> >    libcdr-0.1.4nb6
> >    gource-0.40nb13
> >    gource-0.40nb13
> >    source-highlight-3.1.8nb7
> >    source-highlight-3.1.8nb7
> >    libvisio-0.1.6nb7
> >    libvisio-0.1.6nb7
> >    librevenge-0.0.4nb7
> >    librevenge-0.0.4nb7
> >
> > It does not happen on every build, but it happens a lot, and when it
> > happens it's always a matter of leaving behind the entry for the prior
> > copy of the depending package, whether or not it's the same version.
> >
> >
> > handy check script:
> >
> >    (cd /var/db/pkg && grep . */+REQUIRED_BY | sed 's,^\([^/]*\)-[^-/]*/+[^:]*:\(.*\)-[^-]*$,\1 \2,' | sort | uniq -dc)

This perhaps relates to the discussion on this list last July, where
Mark Davies noted:

>I can generalize this to any set of packages that have an upper bound on
>the required package version that you then use "make replace" to go
>beyond that version of the required package, then replace the requiring
>package.   The required package will end up with both the old and new
>versions of the requiring package in its +REQUIRED_BY file.

http://mail-index.netbsd.org/tech-pkg/2018/07/18/msg020062.html

That was in response to a specific example I'd raised with osabi and
x11-links where the same problem was happening:

http://mail-index.netbsd.org/tech-pkg/2018/07/18/msg020055.html

Regards,

Dave




Home | Main Index | Thread Index | Old Index