pkgsrc-Users archive

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

Re: pkg_rolling-replace

Chavdar Ivanov <> writes:

> 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
> llvm-10.0.1 got successfully built, but as llvm-10.0.0nb1 was
> installed, it didn't replace it.

Are you really sure your tree has no local changes?  If there is a
conflict and conflict markers, various tools behave badly.

Run "pkg_chk -uq" manually.  llvm should be in it, but it seems it is
not.   llvm should show up in MISMATCH_TODO.

Another bug is that llvm didn't show up as a dependency.  read the pkg_rr
code, around line 463.   Run those commands in clang, and see if llvm is
listed as a dependency.

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

That's what I needed to know.  It should have gotten into MISMATCH.

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

What you are doing is perfectly reasonable.  I use -k because my
computer makes more progress when I am not paying attention.  In theory,
and I think mostly in practivce, anything replaced later after fixing
will result in further replaces in order, so things should end up ok.

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

You said "queued before"; do you mean "python37 is in MISMATCH but
things are misordered" or "python37 is not in MISMATCH"?

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.

Attachment: signature.asc
Description: PGP signature

Home | Main Index | Thread Index | Old Index