Application Packaging and Distribution

Registered by James Page

Server (and specificallyJava) applications present a challenge in terms of packaging for Ubuntu. Alternative packaging and distribution methods should be considered to ensure that Ubuntu can support server application requirements whilst minimising overheads.

Blueprint information

Robbie Williamson
Clint Byrum
Needs approval
Series goal:
Informational Informational
Milestone target:
Started by
Robbie Williamson
Completed by
Robbie Williamson

Related branches



I think this one really got split into two different BIG things:

The "Make it easier to package stuff" BP is here:

The "Make it easier to find packaged stuff" BP is here:

I'll be working on both, and I think you are signed up for the auto-generate-packaging stuff as well.

So I think this BP should be marked as dependent on those two, and then we will revisit where we're at for uds-o.

Content from ideas pool:

* Server Conduits - Server Applications and Services that do not fit into the 6 month release cycle will be better off living outside the normal archive release pattern. PPAs have all the functionality necessary already to group packages and dependencies to ride on top of the core releases. There is just need to define the policy and communication around getting these visible in the default apt package lists.

* upstream conduits vs. post-release applications in server land: what solution for a Java world
     * a.k.a. Java stack packaging approach

Topics for discussion:

* Policy of when server applications and services should sit outside of the normal release cycle
  * Contributing factors
    * Frequency of upstream
    * Complexity of dependencies/overlap with Ubuntu
    * Demand for application or service
    * Plans for build-from-source packaging

* Where upstream development methodology does not fit with build from source
   * Java stack packaging approach
     * Build from source or binary packaging?

* Distribution metholodology
  * Options:
    * PPA - have all the functionality necessary already to group packages and dependencies to ride on top of the core releases.
    * Upstream conduits?
  * Challenges: visibility from update-manager/apt

* Roles in packaging and distribution

* Other Considerations
  * Security vulnerability monitoring and patching
  * SRU equivalent processes.

* Examples to support discussion from Maverick
  * Cassandra
  * Hadoop
  * Terracotta

* Potential candidates for Natty
  * Hudson
  * JEE Application Servers
  * + Others


Work Items

Dependency tree

* Blueprints in grey have been implemented.