Hi all, > Are you looking for dependency chains from a web api down to hardware level?
Ideally, yes, although getting that's increasingly looking like an unrealistic goal; for example, tizen.bluetooth (libwrt-plugins-tizen-bluetooth-impl.so) has build dependency chains like: tizen.bluetooth -> capi-network-bluetooth -> bluetooth-api -> syspopup-caller -> aul -> rua -> db-util -> sqlite3 and that's not even into the kernel yet. Just getting dependencies understood to the level of upstream sources looks like a significant undertaking all by itself. Interestingly, tizen.bluetooth doesn't have a direct dependency on bluez; is that interaction via dbus? Steve Gerken ------------------- Linux Developer MSX, as broker for Jaguar Land Rover One World Trade Center, 121 SW Salmon Street, 11th Floor, Portland, Oregon, 97204 Email: [email protected] On 19 November 2013 07:47, Ylinen, Mikko <[email protected]> wrote: > > On Mon, Nov 18, 2013 at 5:45 PM, Hanchett, Paul < > [email protected]> wrote: > >> So the only ways to validate a configuration are: >> >> 1. Have a deep and intimate understanding of the dependencies by >> examining the source code and comparing to the actual configuration, or >> 2. Have and run (up to date!) exhaustive unit and integration testing >> against the JavaScript functionality? >> >> It seems like this approach places a rather large burden on whoever >> configures the system, don't you think? We're talking about an awful lot of >> code here! >> >> One alternative would be to explicitly document the chain of dependencies >> at some level. >> > > Other than the two (messaging, amb) plugins using dbus, the dependencies > are pretty well covered, right? > Are you looking for dependency chains from a web api down to hardware > level? > > -- Mikko > >
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
