Styles of Packaging

[Emmet Hikory]

Mike Carifio wrote:
> I would opine that many application developers are more than annoyed,
> they're lost. So presenting them with all the various variants and
> then asking them to select the right one based on criteria they neither
> appreciate nor care about pretty well assures that many will silently
> walk away.
> I know I'm saying the same thing a different way, but it bears repeating.

    Oh, indeed.  There should be a simple default method presented for the
ease of this audience.  My fear is only that if we push too far, we lose the
ability to handle exceptions, or fall into painful bikeshedding about the
"one true way" when in practice the judgement should be on the end, rather
than the means.

> As I understand it, "policy based" packaging just means "declarative"
> and declarative means I can state *what* I want and the toolchain
> will figure out the *how*. I don't find that true in practice, however.
> I find that I state the what in debian/control, then figure out the how in
> debian/rules and then figure out why I didn't say it all properly. So I
> google and find a thicket of various approaches and workflows which only
> serve to confuse me more.

    Your understanding matches mine.  For purposes of "how", I currently
believe that the use of /usr/share/doc/debhelper/examples/rules.tiny should
be complete from the perspective of application developers: nearly anything
else may well indicate issues with the underlying build system.  That said,
from the perspective of distribution developers, I think it's important to
understand debian/rules as something supporting an API for package creation
and interaction to support uncooperative, abandoned, or strongly opinionated
upstream developers when others are handling the packaging.  Ensuring that we
can support both audiences from the same documentation is tricky, but it should
be our goal.

> I see packaging as something we want the app developer to do. They have
> the most knowledge about their application. Given a
> reasonable bar, I think they will actually do it. After all, they're
> written the application and they want to see it used.
> If/when Ubuntu's popularity grows, then the incentive to package will
> grow. But let us never forget that this is a tax
> they must bear to integrate into Ubuntu. If the tax is too high, they
> just won't do it. So we may appreciate a policy-based approach,
> the richness of many toolchains and so on. But *they* don't, unless it
> makes their lives easier. Note that I'm not saying that
> packaging is easy. I'm just saying it can't be a research project for
> each rookie developer who wants to take a shot at it.

    There have been many discussions in the past about generating documentation
targeted to recommended procedures for build systems and release procedures for
application developers to support the ease of packaging.  Ideally, it should be
possible to generate distribution artifacts that support near automated packaging
for a variety of distributions (for debian-format distributions, this reduces to
a need to write the Description and review if multiple binary packages are needed
from a source artifact).  This goes well beyond packaging and much is unlikely to
be specific to an individual distribution, but is likely worth constructing, if
there are sufficient members of the class of application developers willing to
help define the nature of the issue (I'm not convinced it's something that
distribution developers can see well enough to write well).

    Examples of things to address here might be handling init systems, writing
man pages, use of .desktop or .service files, ensuring build systems allow for
varied build and installation paths, documenting copyright and licensing
assertions, modular configuration file handling, and similar issues.

    In my opinion, it would be best to have this also be a policy-based model,
rather than an implementation-based model, but I suspect a simple set of
recommendations can be constructed for common toolchains (e.g. "If you're
writing a desktop GUI in ruby, here's what you want to do to make it easily
distributable.  If you wrote it in python, you likely want to use this entirely
different toolchain to do the same thing."), and that such documentation of best
practices for application developers would reduce impression of integration tax,
as the volume of effort to package something for a given target is significantly
reduced.

-- 
Emmet HIKORY