Kiss doesn't reinstall depedencies first when updating

[TAAPArthur]

So I've encountered a related issue. Had a problem with non-make depends.
Was updating after a long time and alsa-utils and its depedency alsa-lib were out of date

kiss b alsa-lib alsa-utils

(or kiss u when they are out of date) will build alsa-lib first but not install it even though it is needed to build alsa-utils. I believe kiss thinks that since alsa-lib (an older version) is installed it can build alsa-utils fine

Wanted to confirm this theory and see if new packages didn't have this problem.

kiss new A 1
kiss new B 1
echo "A" > B/depends
KISS_PATH=$PWD  kiss b A B

And this build A, install A and builds B which is correct.

Seems similar to #29, but worse as the update fails but also easier to solve.

[dilyn-corner]

Can you test with Dylan's work?

[TAAPArthur]

@dilyn-corner Tested and the issue isn't resolved yet. Automated the test in #53

[dylanaraps]

Working on it.

[dylanaraps]

I've fixed the make dependency issue. The 10-install-depends-in-correct-order-when-building.sh test failure is a non-issue as it tries to simulate an update using kiss b which obviously doesn't work. The behavior expected by the test is contrary to how the package manager works and would require changing its behavior. ie, it's a bug report if anything. Not something unexpected.

[dylanaraps]

This bug may have been fixed (or at the very least made fixable) by my other changes to pkg_build. Will rebase on master.

[TAAPArthur]

First off, I believe I misrepresented the initial problem. I was updating my system and that failed because one of the packages didn't compile. I then manually tried to update via kiss b and ran into the aforementioned issue. Can confirm that kiss u handles this case correctly.

To @dylanaraps' point, guess you'd be the authority of what's expected. Personally, I viewed kiss u as something that just got updated packages and passed them to kiss b and kiss i so expected dependency handling to be the same between them. However I also agree it seems trivial to obtain my desired behavior the way the code currently is. Will send out a PR since this doesn't seem to be the focus on #43.