move to use v5.36;
tested by me over the last few weeks, and tb@
also fixed a "manual install" bug properly reported by tb@

aside that there should be *no functional change*.
If you see any message like "hey, the number of params is wrong"
it is a fringe case I didn't run into and should be easy to fix.

the solver needs some love for later

move the interface to SharedLibs to be somewhat object oriented

accordingly, load it "just in time" in State.

Most calls get simplified, and we can save more state for later.

under some circumstances, we end up with libexecinfo -> BaseSystem being
recorded as a new dependency. Even though ForwardDependencies normally
takes care of that, with tags, this is not enough.

(this happens only because libexecinfo was a "tight" dependency, thus
resulting in a large UpdateSet, and when some of the objects did require
tags in the new package, and when the order of things meant that BaseSystem
was considered a bit early).

Since there's no handle at this point, a dirty but efficient test vs
BaseSystem will do (which is not a valid normal package name anyhow)

tested to fix the obnoxious warning landry@ saw, which I was able to
reproduce on a box...

with tags, we do look in deletesets
add an extra indirection so we don't look where we actually can't
because the code doesn't exist.
(as seen by various people on somewhat buggy installs)

style

what was I thinking. No need to iterate, just use the key
and avoid a stupid bug where we leave the iterator mid-range

ahah. complex tag changes show I need to use the same algorithm as for libs

make it possible to remove old packages with erroneous tags...
shouldn't happen, but...
- mark old handles as such in UpdateSets
- keep going on solve_handle_tag to get maximum reports
- tweak verify_tags to demote old handles to warnings from errors

fix ::lookup interface return, oops

special case: @tag found in self may have NO parameters and just be used
as a placeholder to tell WHEN you need to run the at-end tag

implement tag checking during normal solving
also keep going after first tag check fail, so that we get maximal checks

style

move the tag base code into SolverBase, and use it in PkgCreate, so that
we refuse to create packages with tags without reachable definitions

split the common half of dependencies handling into SolverBase, as PkgCreate
only uses that

prepare to split half of the dependencies code into a manageable subclass

under some circumstances, we end up with libexecinfo -> BaseSystem being
recorded as a new dependency. Even though ForwardDependencies normally
takes care of that, with tags, this is not enough.

(this happens only because libexecinfo was a "tight" dependency, thus
resulting in a large UpdateSet, and when some of the objects did require
tags in the new package, and when the order of things meant that BaseSystem
was considered a bit early).

Since there's no handle at this point, a dirty but efficient test vs
BaseSystem will do (which is not a valid normal package name anyhow)

tested to fix the obnoxious warning landry@ saw, which I was able to
reproduce on a box...

with tags, we do look in deletesets
add an extra indirection so we don't look where we actually can't
because the code doesn't exist.
(as seen by various people on somewhat buggy installs)

style

what was I thinking. No need to iterate, just use the key
and avoid a stupid bug where we leave the iterator mid-range

ahah. complex tag changes show I need to use the same algorithm as for libs

make it possible to remove old packages with erroneous tags...
shouldn't happen, but...
- mark old handles as such in UpdateSets
- keep going on solve_handle_tag to get maximum reports
- tweak verify_tags to demote old handles to warnings from errors

fix ::lookup interface return, oops

special case: @tag found in self may have NO parameters and just be used
as a placeholder to tell WHEN you need to run the at-end tag

implement tag checking during normal solving
also keep going after first tag check fail, so that we get maximal checks

style

move the tag base code into SolverBase, and use it in PkgCreate, so that
we refuse to create packages with tags without reachable definitions

split the common half of dependencies handling into SolverBase, as PkgCreate
only uses that

prepare to split half of the dependencies code into a manageable subclass

with tags, we do look in deletesets
add an extra indirection so we don't look where we actually can't
because the code doesn't exist.
(as seen by various people on somewhat buggy installs)

style

what was I thinking. No need to iterate, just use the key
and avoid a stupid bug where we leave the iterator mid-range

ahah. complex tag changes show I need to use the same algorithm as for libs

make it possible to remove old packages with erroneous tags...
shouldn't happen, but...
- mark old handles as such in UpdateSets
- keep going on solve_handle_tag to get maximum reports
- tweak verify_tags to demote old handles to warnings from errors

fix ::lookup interface return, oops

special case: @tag found in self may have NO parameters and just be used
as a placeholder to tell WHEN you need to run the at-end tag

implement tag checking during normal solving
also keep going after first tag check fail, so that we get maximal checks

style

move the tag base code into SolverBase, and use it in PkgCreate, so that
we refuse to create packages with tags without reachable definitions

split the common half of dependencies handling into SolverBase, as PkgCreate
only uses that

prepare to split half of the dependencies code into a manageable subclass

style

what was I thinking. No need to iterate, just use the key
and avoid a stupid bug where we leave the iterator mid-range

ahah. complex tag changes show I need to use the same algorithm as for libs

make it possible to remove old packages with erroneous tags...
shouldn't happen, but...
- mark old handles as such in UpdateSets
- keep going on solve_handle_tag to get maximum reports
- tweak verify_tags to demote old handles to warnings from errors

fix ::lookup interface return, oops

special case: @tag found in self may have NO parameters and just be used
as a placeholder to tell WHEN you need to run the at-end tag

implement tag checking during normal solving
also keep going after first tag check fail, so that we get maximal checks

style

move the tag base code into SolverBase, and use it in PkgCreate, so that
we refuse to create packages with tags without reachable definitions

split the common half of dependencies handling into SolverBase, as PkgCreate
only uses that

prepare to split half of the dependencies code into a manageable subclass

what was I thinking. No need to iterate, just use the key
and avoid a stupid bug where we leave the iterator mid-range

ahah. complex tag changes show I need to use the same algorithm as for libs

make it possible to remove old packages with erroneous tags...
shouldn't happen, but...
- mark old handles as such in UpdateSets
- keep going on solve_handle_tag to get maximum reports
- tweak verify_tags to demote old handles to warnings from errors

fix ::lookup interface return, oops

special case: @tag found in self may have NO parameters and just be used
as a placeholder to tell WHEN you need to run the at-end tag

implement tag checking during normal solving
also keep going after first tag check fail, so that we get maximal checks

style

move the tag base code into SolverBase, and use it in PkgCreate, so that
we refuse to create packages with tags without reachable definitions

split the common half of dependencies handling into SolverBase, as PkgCreate
only uses that

prepare to split half of the dependencies code into a manageable subclass