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

[Emmet Hikory]

Mike Carifio wrote:
> On 12/17/2012 08:11 PM, Emmet Hikory wrote:
> > packaging guide, I think there is value in being clear that folk who wish to
> > package have a plethora of options available: by all means, let's advocate the
> > latest labour-saving mechanisms, but at the same time, I think we need to
> > avoid anything that implies there is some magic one true way to package.  At
> > least in the current text presented at developer.ubuntu.com, the suggestions
> > on packaging new software recommend local compilation, which often hides all
> > sorts of issues, although it significantly reduces the apparent setup required
> > to get involved: I don't believe there is a good answer as to how folk should
> > do this: some may prefer to set things up to match what they think most
> > developers use, and others may just want to get something done.  Similarly,
> > we're recommending use of dh-make, and then recommending deleting all the
> > example files that it produces: this is another case where there may be more
> > value in having two paths: one that goes through the dh-make files, and the
> > other that just focuses on changelog, compat, control, copyright, and rules
> > (of which 60% are trivially generated automatically).  Different folk learn
> > differently, and as long as we're documenting things that we expect to be
> > used not only for new packaging, but also for patching existing packages,
> > it behooves us to ensure that we have coverage of all the different ways that
> > packages might behave, and some guidance on how to discover when to apply any
> > given rune from some assembled grimoire (assuming it will take some practice
> > for folk to learn the tools well enough to remember how to do things without
> > looking at their notes).
> >
> 
> I come at this differently. Although we may take packaging seriously, I
> would say that many devs don't view it
> as the main event. They are looking for the one true way to package
> because its a means to an end. If there isn't one
> or isn't a small number of them, then maybe that's an indication of a
> deeper problem.

    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.

    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.

[0]: Whatever that recommendation ends up being: the specifics identified above
represent a guess on my part from a quick perusal of one small section of the
current guide several hours ago, and while I expect to review some aspects of
the guide, I am most certainly not authoritative in terms of the recommendation
that may be present there at any given time.

-- 
Emmet HIKORY