Summary

Rationale

Many developers do not wish to learn to package, or claim that it is too complex. Often these same people will be working on projects which do not require complex packaging, or the implied familiarity with the system, tools and processes. Providing these developers with tools which can autogenerate packaging for them would remove one of the barriers to distributing their code on Ubuntu, while still having the package managed by dpkg, and without removing the ability to modify the packaging if the complexity of the project grows.

Several tools, such as debhelper, quickly, python-stdeb, python-mkdebian and dh-make-perl have shown the utility of an approach which knows how to deal with specific classes of package. Following this style will provide an extensible system that can cope with the multitude of technologies developers can use.

User stories

Assumptions

Design

"quickly package" points to an approach that will serve us well.

It makes use of python-mkdebian, with certain options, to create the packaging by introspecting the projects.

However, it is tied to Python code, so we want to make it generic. We don't want to rewrite it for every language, as much of what it does is language independent.

We should then define an interface which language/project style communities can implement in order to provide the information that is not generic.

Looking at the information that can be provided:

The tool should also be able to work incrementally, i.e. with an existing debian directory. This means that you don't need to understand how to add a new build dependency to the packaging, or to cope with the packaging implications of other changes you make.

We also may want "3-way merge" of the packaging, so that it can handle manual changes to the packaging.

Implementation

This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.

Migration

Include:

Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.

This need not be added or completed until the specification is nearing beta.

Unresolved issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Want to autogenerate as much as possible. Don't need new binary format.

Don't need to handle complexity of everything in Ubuntu.

Some existing packages are crufty for historical reasons. Are simplifying such things in scope? Sort of. Maybe by blowing away debian/, autogenerating, and seeing what breaks.

Not just fire-once, but also for handling updates and such.

Designed for authors themselves, not Ubuntu developers. Less work for us by not overriding what upstream does.

Start by focusing on packages that generate just one binary package.

Tried to extend dhmake, but was not architected like we need.

Existing stuff: dhmake, python-stddeb, quickly. Last two only work for python. Want more extensible solution.

We don't care about patch systems, this is for upstream.

Subproblems:

What about making sure copyright file is valid? Autogenerating it by looking at code?

Packaging binary artifacts like .jar files... Not easy to package mass amounts of java with weird build systems. Easier to stuff jar files.

debhelper is pointing in a good direction with figuring out what you are trying to do.

Changelog. Version number is only required bit.

Licensing is also poorly understood frequently by developers. Not odd for no copyright headers in source.

This tool is a layer below the IDE or quickly. Education to user is probably more appropriate in that IDE layer.

Rules:

Control:

What about dependencies?

Backend should probably have a hook in everything, just in case, but mostly expect them only for a few things like dependencies.

Misc. files like .install, .links, etc. dh7 introspects most of that for us today.

Should be able to be incremental. So that if you run again after adding a dependency in source, this would notice.

What language/interface should we have backends in?

What do we need from a backend?

Maybe /usr/share/XXX/BACKEND/hooks/deps or something

Decisions:

Action Items:

CategorySpec

Specs/N/AutogeneratePackging (last edited 2010-10-27 22:03:22 by host194)