[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1029645: ITP: debputy -- Manifest style debian package builder



Package: wnpp
Severity: wishlist
Owner: Niels Thykier <niels@thykier.net>
X-Debbugs-Cc: debian-devel@lists.debian.org, niels@thykier.net

* Package name    : debputy
  Version         : 0.1.1
  Upstream Contact: Niels Thykier <niels@thykier.net>
* URL             : https://salsa.debian.org/debian/debputy/
* License         : GPL-2+
  Programming Lang: Python
  Description     : Manifest style debian package builder


Binary package being dh-debputy:
  Package builder that provides a declarative manifest for building
  debian packages.

  This version integrates with the debhelper sequencer dh and will
  replace several of debhelper's tools that are covered by debputy.

  The debputy package builder aims to reduce cognitive load for the
  packager and provide better introspection to better support to
  packagers, linters and the Debian janitor.


The early versions will integrate into the debhelper sequencer dh and will replace several of debhelper's tools that are covered by debputy. However, the goal is that debputy will be a standalone tool capable of packaging work from start to end.

In the early phase, I plan to keep debputy in experimental to allow for more aggressive prototyping.

Rationale:
==========
My work on debputy is aimed at exploring an alternative packaging format that focuses on a single manifest (think Kubernetes helm charts or docker compose files). A key goal is introspection and, for errors, a clear link to the part of the configuration that was involved or triggered the error.


Maintenance:
============
I am looking for people, who are interested in exploring this area with me and are:

  1) Interested in trying the prototype, or/and
  2) Interested in helping me design the manifest format, or/and
  3) Interested in helping me develop the tool, or/and
  4) Interested in integrating with the tool.
     - Whether third-party plug-in (a la dh add-ons) or linters/fixers

As some concrete suggestions for what a contributor might be helping me with. The list is not exhaustive and you are welcome to help regardless of whether your interest is mentioned above. :)

Trying out debputy:
===================

There is a getting started guide at https://salsa.debian.org/debian/debputy/-/blob/main/GETTING-STARTED-WITH-dh-debputy.md.

If you do not use any overrides/hook targets, it is question of running:

 # (Remove --no-act to actually perform the change)
 $ debputy migrate-from-dh --no-act

And then add `dh-sequence-zz-debputy` to Build-Depends (the `zz-` is a hack for ordering debputy after other addons).

Key features:
-------------

Some high lighted features in debputy that are currently not available in other Debian packaging tools that might be interesting for you :)

 1) debputy supports setting static ownerships inside the debs without
    relying on fakeroot.  This means that packages never need fakeroot
    for the Debian packaging side (i.e., you should always be able to
    use `Rules-Requires-Root: no` as long as the upstream build system
    behaves).

    This feature is mentioned in the GETTING-STARTED-WITH-dh-debputy.md
    document, so you can see how to use it / try it out.

 2) If a binary package does not have a Multi-Arch field, debputy will
    automatically deduce if it is safe to set "Multi-Arch" to "same".
    The mechanics are based on rules by Helmut Grohne, who proposed this
    feature on IRC.  In the rare cases, that debputy is wrong here,
    you can explicitly set "Multi-Arch: no"

On the flip side, there are tons of features *not* supported by debputy at the moment.

Thanks,
~Niels


Reply to: