Comment 1 for bug 1399687

I'd like to avoid doing the split of the version_detail field in the client. It's guaranteed to be a comma separated list of key=value pairs, so it should be relatively easy for the consumer of this information to do the split.

The reason I'd like not to do it in the client is that we have a flat namespace in the mapping returned by .Information(), and the version_detail keys could be anything, so as implied in the description, we'd have to craft a naming scheme to prevent name collisions. At that point, any client would have to undo the naming scheme (e.g. a unique prefix) and then it seems just as easy for the client to do the split and not worry about de-prefixing.

I think it will be okay to include the target version detail in the -cli's --info output without an additional flag. While for practical purposes, the format of --information output is part of its API, I make no guarantees that it will not change or even be backward compatible.

One interesting possibility is to add a --json to --info, such that the output would be JSON compatible. That could make it easier to parse the cli's output.

Also, it's important to understand that retrieving the target's version_details isn't really possible currently, without actually downloading and installing the update. That's because the version_detail string is taken from the channel.ini file, and the target's version of that is embedded in the update's data file. It's not available even in the index.json file, so it's not like we can check for update and then provide that information (at least, not without a change to the server code to insert it into index.json, which isn't a bad idea, and I'll ask stgraber about that). E.g.

http://system-image.ubuntu.com/ubuntu-core/devel/generic_amd64/index.json