Improve cloud libraries in ubuntu

Registered by Scott Moser on 2010-04-28

In Lucid we packaged many new AWS libraries. Again we'd like to look at which libraries and tools make sense to have in the distribution and package them up. This is not necessarily limited to AWS libraries.

Blueprint information

Status:
Complete
Approver:
Jos Boumans
Priority:
Low
Drafter:
Scott Moser
Direction:
Approved
Assignee:
Thierry Carrez
Definition:
Approved
Series goal:
Accepted for maverick
Implementation:
Implemented
Milestone target:
milestone icon maverick-alpha-3
Started by
Thierry Carrez on 2010-07-28
Completed by
Thierry Carrez on 2010-07-29

Related branches

Sprints

Whiteboard

Status:
Completed.

Complexity:
maverick-alpha-3: 1

Work items maverick-alpha-3:
[ttx] Test jets3t from Debian to verify functionality: DONE
[ttx] Review other cloud libs and update them if needed: DONE

Reviewers: ttx + jib

ttx review / 20100526:
 * Missing Design section -- could use an updated table to see the current language support (like on the lucid spec)
 * Missing Java build dependency analysis for typica and jets3t, it's probably way more work that you think (welcome to the Java packaging hell)
   * At first level, Typica requires packaging Httpclient 4 (we only have commons-httpclient 3) and Glassfish JAXB first (or check that it would accept jaxme instead), and build deps of them...
   * At first level, jets3t ships with plenty of JARs under libs/, each of those would probably need to be packaged (or checked for a possible already-packaged match/replacement)
 * Suggested assignees: smoser / ?
 * Estimated complexity: 3++ based on dependency analysis
 * Suggested priority: 3/Low (added value of random Java library packaging is low, since Java devs won't use the packaged stuff anyway)
 * Suggested Subcycle: Iteration 1 or 2 (Alpha2 or Alpha3)

jib review 20100526:
  * if we already predict low value at this point, I suggest not pursuing this spec during maverick.
    * jets3t is in Debian, I suggest keeping complexity=1 and ensuring that gets imported and works correctly -- ttx
  * alternately, package in Multiverse for easy access and track uptake
    * Note that dropping a package in multiverse because you don't have time to properly package dependencies (rather than because it has unsolvable/badly-licensed ones) is very much frowned upon. Multiverse is not a drop zone for half-baked packages, so this option should be reserved for extreme cases -- ttx

Comments:
- [2010-05-25/smoser]
  - time estimate: 1 week

(?)

Work Items