Re: pkg_rolling-replace

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

After manually forcing the updates of the packages mentioned above, I
proceeded with 'pkg_rolling-replace -uvk' and eventually almost
completed the full replacement; the most problematic package on this
particular pkgsrc host turned out to be kde-runtime4, which has been
failing for me for quite some time. So far so good.

I have another vm with pkgsrc setup, which was done for a different
reason and is much smaller in terms of the number of packages built -
less than 800 (the other one has about 3400). On this one I also get
the same problem with pkg_rolling-replace:

 egrep A\ different /root/rr-01.log    <====== rolling-replace log file

pkg_add: A different version of perl-5.32.0 is already installed: perl-5.30.3
....
pkg_add: A different version of perl-5.32.0 is already installed: perl-5.30.3
pkg_add: A different version of libcups-2.3.3nb5 is already installed:
libcups-2.3.3nb3
pkg_add: A different version of ghostscript-9.05nb23 is already
installed: ghostscript-9.05nb22
pkg_add: A different version of libcups-2.3.3nb5 is already installed:
libcups-2.3.3nb3
...
pkg_add: A different version of libcups-2.3.3nb5 is already installed:
libcups-2.3.3nb3
pkg_add: A different version of libv4l-1.18.1 is already installed:
libv4l-0.4.3nb4
pkg_add: A different version of libcups-2.3.3nb5 is already installed:
libcups-2.3.3nb3
...
pkg_add: A different version of libcups-2.3.3nb5 is already installed:
libcups-2.3.3nb3

So
   a) what would the lege-artis way be to upgrade perl from 5.30.3 to 5.32.0?
   b) why minor package updates like libcups and ghostscript are not
detected for a replacement?



On Mon, 31 Aug 2020 at 00:42, Greg Troxel <gdt%lexort.com@localhost> wrote:
>
>
> Chavdar Ivanov <ci4ic4%gmail.com@localhost> writes:
>
> >> Are you really sure your tree has no local changes?  If there is a
> >> conflict and conflict markers, various tools behave badly.
> >
> > I ran pkg_chk, there were very few problems. One package had mixed-up
> > Makefile, perhaps due to an early local change; I reloaded all files
> > for it. There are a number of packages installed from wip, some of
> > them with dependencies from wip, which later have been moved to the
> > main pkgsrc or even removed; I dealt with these manually. There were
> > also a bunch of obsolete packages installed, which were only leaf, I
> > removed them (two from x11, related to printing, and about 10-12 tex-
> > packages).
>
> So if you do "cvs up" in /usr/pkgsrc, and save the output, then:
> 1) there are no lines starting with "C"
> 2) For every line starting with "M", you have run diff and you are sure
>    it's ok?
> or do you mean something else?
>
> >> Run "pkg_chk -uq" manually.  llvm should be in it, but it seems it is
> >> not.   llvm should show up in MISMATCH_TODO.
>
> You did not answer this.  This is a critical point.
>
> > This is what comes from the pkg_rr log:
>
> Sure, but the problem is that llvm is not in MISMATCH_TODO, not what
> happens when clang is built.   What happens when clang is built is a
> symptom of not having replaced llvm first.
>
> You need to figure out why llvm was not in MISMATCH_TODO, which means
> pkg_chk -uq and seeing if it is there.  And perhaps "make
> show-downlevel" in lang/llvm.
>
> > pkg_rr somehow has failed to notice that llvm also needs an update and
> > it needs to be done ahead of the clang update - as a result of the
> > sort.
>
> Yes, and I have been asking you to figure out why and how.
>
> >> >> Can you find out from the output (that I hope you saved) whether llvm
> >> >> was on the MISMATCH list?
> >
> > That is. llvm was not listed in any of the lists.
>
> That is very wrong, and we need to find out why it is not.
>
> >> You said "queued before"; do you mean "python37 is in MISMATCH but
> >> things are misordered" or "python37 is not in MISMATCH"?
> >
> > The lists above do not show python3.7. The presently installed version
> > is 3.7.8. py37-sqlite3 shows dependency on python3.7.9 and builds it,
> > but the installation fails again, as python3.7.8 is installed.
>
> There is something very wrong, and others do not report this.   Please
> run "pkg_chk -uq" and see if python37 and llvm are reported as
> mismatched.  If they are not, this is not a pkg_rr problem.
>
> > Basically the same as with clang/llvm. I then manually replaced python
> > and reran pkg_rr, which then caught all other py37 packages for
> > replacement.
>
> No real surprise there!
>
> >> Also, pkg_rr, pkg_chk, and tools in general, do not deal well with
> >> multiversion things like pyNN-foo, but they are msotly ok for the
> >> default version.
> >
> > They also do not deal well with packages having the same name. but
> > different underlying versions - e.g. pkg_chk showed
> >
> > archivers/py-zipp1 - py37-zipp-3.1.0nb1 > py37-zipp-1.2.0 - ignoring
> >
> > (it sees that py-zipp1 package should be also called 'py37-zipp' and
> > as the installed version is higher, it ignores it - but it will miss a
> > new version of py-zipp this way, or so I think).
>
> Yes, that's also tricky.  Perhaps also a bug in pkg_chk, perhaps not.



-- 
----