Styles of Packaging (was: Deprecating the wiki-based Packaging Guide)

[Steve Langasek]

On Tue, Dec 18, 2012 at 03:16:13PM +0900, Emmet Hikory wrote:

>     While it may appear that way at first glance, this is very much an
> intentional consequence of policy-based packaging, which Ubuntu inherits
> from Debian.  By having packaging judged against policy, rather than
> against some arbitrary implementation, we are free to continuously
> innovate in our use of tools to improve our packaging.  Innovations that
> lead to interesting consequences frequently become policy, such that all
> other packaging toolchains in the archive are expected to support the
> expected results (or be retired).

>     However, as this has been an ongoing process of competitive
> improvement of the several toolchains over more than 20 years, and as many
> packages have not been updated in some time (this may be by design: e.g. 
> mpi-specs, which likely won't be updated for many more years to come), and
> many "how to package" documents are floating around the internet, this
> means that every possible experimental means of packaging is documented
> somewhere (and may show up in your favorite search engine), and many of
> them are used for packages extant in the current archive.

>     There is definitely a set of tools that are currently the most popular
> in the Debian archive, and these integrate well with a set of tools being
> developed under the "Ubuntu Distributed Development" moniker, which
> combination may well likely be that which is recommended by the Ubuntu
> Packaging Guide under development: as such, this recommendation [0] is
> what ought be followed by the class of developers for whom packaging is a
> means to an end (as they are often focused on a specific piece of
> software).  For folk who might focus on packaging as an end, preferring
> the role of distribution developer to that of application developer, there
> is a need for a greater understanding of the underlying policy and the
> massive variety of tools by which this policy may be implemented.

People who are aiming to contribute to Ubuntu as a distribution absolutely
need to master a different set of skills than those who just want to package
up their own software.  In terms of developer documentation, I think the
important goals are that:

 - We make sure everyone has a handle on the second category before they
   tackle the first category.
 - We avoid annoying or distracting developers who only care about the
   second category with information that's only relevant in the first
   category.
 - We ensure that developers who are looking to participate in Ubuntu
   development can find the information they need from the same entry point.
 - We ensure that the recommendations that we're giving developers for
   creating packages for their software aren't at odds with the consensus
   among experienced Ubuntu developers about how a package should look.

I think the current Ubuntu Packaging Guide is doing a reasonably good job of
walking this line.  Where it isn't, I'm sure bug reports are welcome.

>     Where this is understandably annoying for the application developer is
> that the recommendation is subject to change over time, as newer tools are
> developed and adopted: we tend to select toolsets that provide the most
> automation while leaving us the facility to make local exceptions to
> standard processing as appropriate for specific packages, which may appear
> to require an application developer to relearn from scratch every so many
> years.  In practice, the lifecycle of a toolset is typically much longer
> than the period during which it is the most popular for use, and it is
> rare for toolsets to be entirely retired (although in some cases the
> maintainer of the packaging toolset may declare they no longer intend to
> support it, and it will only live on if someone else is willing to update
> it to support current policy).  As a result, once one learns some means of
> packaging, one may usually continue with that method for a fairly long
> time without need to change unless one is excited about new features of a
> newer toolset.

Where package tooling has changed recently, it has mostly been about
incremental improvements rather than revolutionary changes.  At the
packaging level, http://people.debian.org/~cjwatson/dhstats.png shows that
dh(1) has had dominant mindshare for over 3 years (shown by the constant
growth in usage), and if it doesn't quite yet represent the way the majority
of packages in the archive are done, this has more to do with the inertia of
existing packages than with any lack of consensus.  Prior to the advent of
dh(1), there *was* a distinct lack of consensus, with developers divided
roughly equally between cdbs and debhelper camps.  So I do think it's
important that any documentation that's teaching people how to package focus
on dh, and explicitly relegate non-dh packaging to the category of "here's
what to do if you need to work on an existing package that doesn't follow
best practices".

UDD poses a different set of problems.  I'm not sure how relevant it is to
the upstream developer who just wants to package their software; at the very
least, I think the developer docs should explicitly deal with the
possibility that the upstream has already made a different VCS choice that's
not bzr.  And where Ubuntu development is concerned, I regret that I have to
agree with Scott that the lack of reliability for the existing UDD branches
is a problem, and one that doesn't seem to be getting better over time.  So
while I personally favor the UDD workflow (and fervently disagree with
Scott's claim that it's a "more complex" toolset), I think we do need to
reconsider if it's actually beneficial to steer developers down this path. 
Whether or not there's a consensus that we should be using UDD, it's no use
to new developers if it doesn't actually work.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20121218/f45887b5/attachment.pgp>