#
039cbdaa |
| 13-Jun-2023 |
espie <espie@openbsd.org> |
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
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.
show more ...
|
#
08eb747c |
| 21-May-2023 |
espie <espie@openbsd.org> |
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.
|
#
19395269 |
| 13-Oct-2019 |
espie <espie@openbsd.org> |
name value to shorten code
|
#
b21d7bd4 |
| 23-May-2019 |
espie <espie@openbsd.org> |
look for tag in self first, solves a fringe case where we could find the dependency in another version of the the same package first, and error out (see special case found_in_self).
|
#
9a9cac3b |
| 26-Jun-2018 |
espie <espie@openbsd.org> |
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
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
show more ...
|
#
7e1a3fb3 |
| 24-Jun-2018 |
espie <espie@openbsd.org> |
implement tag checking during normal solving also keep going after first tag check fail, so that we get maximal checks
|
#
112aebab |
| 23-Jun-2018 |
espie <espie@openbsd.org> |
have a default tag value of empty, because.
|
#
4314c9e9 |
| 22-Jun-2018 |
espie <espie@openbsd.org> |
move the tag base code into SolverBase, and use it in PkgCreate, so that we refuse to create packages with tags without reachable definitions
|
#
efe96b40 |
| 22-Jun-2018 |
espie <espie@openbsd.org> |
special case for a tag in self, which should be run appropriately during deletion
|
#
58a15055 |
| 21-Jun-2018 |
espie <espie@openbsd.org> |
split the common half of dependencies handling into SolverBase, as PkgCreate only uses that
|
#
21318713 |
| 20-Jun-2018 |
espie <espie@openbsd.org> |
make it possible to do @tag sthg in the same package that does @define-tag sthg
|
#
6db775b5 |
| 20-Jun-2018 |
espie <espie@openbsd.org> |
so tags will need to match OLD tag definitions as well as new ones. we can probably get away without doing it if no tags exist (to do later)
|
#
9e3252f3 |
| 19-Jun-2018 |
espie <espie@openbsd.org> |
fix solve_tags to deal with the actual list of tags (match tag to tag definitions)
|
#
97050c5c |
| 18-Jun-2018 |
espie <espie@openbsd.org> |
document the reason these classes exist
|
#
9015b27f |
| 16-Jun-2018 |
espie <espie@openbsd.org> |
heh. bug happens so seldom, fix was not 100%
|
#
4fe8a675 |
| 15-Jun-2018 |
espie <espie@openbsd.org> |
fix for the infamous "cups" bug. Finally. the problem was in solve_wantlibs, which is invoked fairly early in the game (before actually committing to install the set) and which would walk the "curren
fix for the infamous "cups" bug. Finally. the problem was in solve_wantlibs, which is invoked fairly early in the game (before actually committing to install the set) and which would walk the "current" dependency tree and solve libs accordingly.
The problem being that sometimes, the libraries were in an older set... so the fix is to do the dependency adjustment at this point as well, to properly peek in the new set.
The main problem with that bug was how hard it was to reproduce, because it depends on several conditions: - the old and new package must have different names, but contain some shared libraries with the same version. - it has to be an UpdateSet with several packages tied together - reaching the library must be possible through several paths. This usually happens after several sets got merged together. - taking the wrong path is dependent on the hash key order of the dependencies, which is random.
show more ...
|
#
bbd77f4c |
| 15-Jun-2018 |
espie <espie@openbsd.org> |
no need to always use 1 for the constant, knowing how it got solved can be fairly useful while debugging.
|
#
2412071f |
| 13-Feb-2018 |
espie <espie@openbsd.org> |
give up a bit on the infamous cups update issue. sort dependencies so that at least this is 100% reproducible...
|
#
bf99a1e9 |
| 05-Nov-2015 |
espie <espie@openbsd.org> |
tweak dependencies handling, might fix some infrequent bugs including the infamous cups bug. - look for candidates in the whole new set first. Yep, that includes kept packages (should make things sli
tweak dependencies handling, might fix some infrequent bugs including the infamous cups bug. - look for candidates in the whole new set first. Yep, that includes kept packages (should make things slightly faster, I expect) - correctly remove caching of list of installed packages outsides of old packages from the current set each time we revisit the set (looking at the old behavior this actually sounds very likely).
show more ...
|
#
8edfe0b8 |
| 14-Aug-2015 |
espie <espie@openbsd.org> |
remove partial to_register from sets when we merge, since we have to do the work again.
Should solve the +REQUIRED_BY problem hopefully.
|
#
5012247c |
| 30-Jan-2015 |
espie <espie@openbsd.org> |
Fix the default interactive level to install the "default" dependencies. Actually testing it caused me to write correct (and simpler) code...
|
#
88e3b4a2 |
| 30-Nov-2014 |
espie <espie@openbsd.org> |
interactive/progressmeter clean-up
|
#
75d33469 |
| 30-Nov-2014 |
espie <espie@openbsd.org> |
clear progress meter before asking questions From Carlin Bingham
|
#
71382144 |
| 01-Feb-2014 |
espie <espie@openbsd.org> |
let solve_depends work as soon as we have update_info
|
#
85d1f632 |
| 24-Dec-2010 |
espie <espie@openbsd.org> |
handle failures from ports tree with more care. this does avoid infinite loops in case of wrong plists. necessary since print-plist-with-depends CAN fail...
|