Hi,

On 8/5/24 17:26, Niels Thykier wrote:

 * Does this package use `gbp dch` [...]
 * Does this package use some form of automatic formatting [...]
 * Does the maintainer prefer MR via salsa or BTS [...]
 * Does the maintainer prefer dgit and if so, which of its 5+ different
   documented workflows should I follow?

The thing is: all of these things are really interfaces, but they have
not been designed as interfaces, they are just exposed parts of the implementation.

What we want is a single machine readable interface that allows updating packages. What we get in this way is a selector for an open set of
possible interfaces, all with their individual drawbacks.

To really use that in an automated fashion, someone will have to develop
a software package that has a single interface and several plugins that implement this interface, and that abstract away the differences between
the exposed-implementation-details-as-interface.

So this does not save us from designing a proper interface, so we might
as well get this done and then add the abstraction layer for the tools
directly into the tools themselves.

Such an interface would assume a backend data model that can accurately represent the timeline of Debian packaging, including

- taking upstream source
- from tarball
- from git
- leave option to support other VCS, but do not waste effort
- removing DFSG non-compliant files
- demarcating the separation between "upstream" and "Debian"
- producing a reproducible .orig archive (with no limit on format)
- adding and updating packaging metadata
- adding, updating and removing patches to the upstream source
(ideally tracking patch author information and patch metadata
information separately
- producing a reproducible .debian archive (with no limit on format)
- listing package history, with events classed accordingly

There needs to be some allowance for backends to be unable to retrieve
some information, simply because the Debian archive does not track contributions line-by-line, and several of the git backends have also
lost information along the way, like the original commit message for a
patch that got copied into debian/patches.

A successful abstraction, in my view, hides the existence of the
debian/patches directory, and represents it as metadata, with the
metadata fields from the patch files themselves, and includes an
interface for "add this patch to the upstream sources at this point in
the patch stack and rebase everything." Whether that uses git rebase or
quilt refresh in the background is of no concern to the interface user.

Of course that will lose most of the "usefulness" of salsa, which does
not expose this high-level view, and cannot easily be made to do so. The
point I was trying to make all along was that this was always a red
herring, and if we want to have good tools, then we cannot tie packaging workflows to the back of a software development workflow just so we
could reuse some of their shiny tools.

Simon

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)