pkgsrc-Users archive

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

Re: pkg_rolling-replace

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

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index