Just so that people can find it. This thread with Stephen Kitt upstream in Karaf:
http://karaf.922171.n3.nabble.com/Understanding-features-and-dependencies-td4050692.html#a4050698

Has Karaf saying that the general issue is our refreshes not dependency resolution being broken. Also, feature:install should not be refreshing bundles as a matter of course. Instead if we're seeing refreshes, that's probably a bug.

This meeting has some notes too around section 2:
https://meetings.opendaylight.org/opendaylight-meeting/2017/nitrogen_release_sync/opendaylight-meeting-nitrogen_release_sync.2017-06-19-15.02.html

• colindixon asks if there are patterns to what breaks in karaf 4 that we can look for (colindixon, 15:12:33)

• skitt says that there are some things which are bugs that happened to work in karaf 3, but don't work anymore (colindixon, 15:13:00)

• https://lists.opendaylight.org/pipermail/netvirt-dev/2017-June/004788.html <== this is, AFAIK, the latest on where netvirt is at (Karaf 4 is NOK; many CSIT still failing for them) (vorburger, 15:13:47)

• other times are when karaf 4 tracks package dependcies much more closely and refreshses things when they change those, in netconf, this seems to have happened when there are package exports that aren't really needed espcially when there are cycles (colindixon, 15:14:57)

• also optional dependecies now trigger refreshes if they become available (colindixon, 15:15:32)

If you do feature:install -v it should note if it refreshes any bundles and if so, why. That should help figure things out.

Upstream’s view on this is that we need to sort out our refresh issues before we start investigating any remaining dependency issues. The default dependency handling should be OK for us apparently.

I’m guessing we might still need prerequisite="true" for some dependencies, e.g. the data broker...

As far as I understood in yesterday's Kernel call, skitt is investigating this..