Re: pkg_rolling-replace

[Chavdar Ivanov <ci4ic4%gmail.com@localhost>]

On Sun, 30 Aug 2020 at 14:29, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
>
> Chavdar Ivanov <ci4ic4%gmail.com@localhost> writes:
>
> > => Creating binary package /usr/pkgsrc/lang/llvm/work/.packages/llvm-10.0.1.tgz
> > ===> Building binary package for llvm-10.0.1
> > => Creating binary package /usr/pkgsrc/packages/All/llvm-10.0.1.tgz
> > ===> Installing binary package of llvm-10.0.1
> > pkg_add: A different version of llvm-10.0.1 is already installed: llvm-10.0.0nb1
> > pkg_add: 1 package addition failed
> > *** Error code 1
> > ....
> >
> > Why is not llvm updated in this context? it is selected for build, the
> > build completes and then it does not replace it.
>
> You didn't include enough context.  Was llvm in MISMATCH_TODO?  What
> package was being replaced? It seems that some package depended on llvm,
> and replacing that package forced a build of llvm, which was an
> 'install', not a 'replace-if-already-present-else-install' target (which
> we don't have!).

The package being replaced at the moment was clang-10.0.1
(clang-10.0.0 was installed at the moment). This obviously requires
the latest llvm, which had to be built, but was not in any of the
three lists (MISMATCH_TODO, REBUILD_TODO and UNSAFE_TODO). So
llvm-10.0.1 got successfully built, but as llvm-10.0.0nb1 was
installed, it didn't replace it.

>
> pkg_rr tries to find the build depends, but I suspect that
>
> A BUILD_DEPENDS on B
> B BUILD_DEPENDS on C
>
> gets the "A B" dependency in the list to be tsorted, and probably does
> not get the "B C".  However, if B depends on llvm and llvm has a version
> chagne B should have been revbumped and be on the MISMATCH list.
>
> > I do 'pkgclean' and 'pkg_admin rebuild-tree' before every attempt to
> > 'pkg_rolling-replace -uv'.
>
> Can you find out from the output (that I hope you saved) whether llvm
> was on the MISMATCH list?

 I can post the three lists, but they are rather long. For whatever
reason pkg_rr hadn't recognized llvm as a package in need of an
upgrade. AS above, llvm was not in any of the lists.

>
> Because there are lots of problems, most of them in individual packages,
> i tend to run pkg_rr with -k, and then clean workdirs and do it again.
> That tends to paper over the kind of problem you are having.

I used to do this as well; now I prefer using only '-uv'. With '-k'
one can let it go over as many as packages it can, but it may leave
the packages in inconsistent state, if I ca say this - I use this
build host as a pkgin server and if I use '-uvk', then get the list
with the '-' at the end and go over each of them, thinking that
everything would be ok, there are still unresolved upgrades from
packages depending on these last ones. So at the moment I run only
'-uv', sorting out each failure as it goes, then cleaning the work
directories and carrying on. Perhaps it is not the right thing, but it
seems better then the previous.

Anyway, this seems to happen more often now, I have several similar
logs (I keep the pkg_rr logs, if they are of interest), e.g. with
python3.7 as well ( some python package using the default 3.7 gets
queued for rebuild before python3.7, which leads to python3.7 being
rebuilt and its installation fail, as the previous version is
obviously installed).



-- 
----