Improve cloud libraries in ubuntu
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.
- Jos Boumans
- Scott Moser
- Thierry Carrez
- Series goal:
- Accepted for maverick
- Milestone target:
- Started by
- Thierry Carrez on 2010-07-28
- Completed by
- Thierry Carrez on 2010-07-29
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/
- time estimate: 1 week