Re: Representing Debian Metadata in Git

From: Blair Noctis <ncts@debian.org>
Date: Aug 22, 2024, 19:27 UTC
Message-ID: <5b59d9f0-74a2-418c-acd7-ff1ecbfea467@sail.ng>
In-Reply-To: <eb963843-9e2c-49f2-911f-fa36f33f9bfd@debian.org>

On 2024-08-20 15:10, Simon Richter wrote: (...)

Show 31 quoted lines

> Right now, git is used mainly as a network file system, and only tagged 
> releases are expected to be consistent enough to compile, because often 
> going from one consistent state to another as an atomic operation would 
> require multiple changes to be applied in the same commit.
> 
> The imported archive is represented either directly as a tree (which may 
> be imported from the upstream project if no files are undistributable 
> for Debian), or via a mechanism that can reproduce a compressed archive 
> that is bitwise identical to the upstream release, from a tree and some 
> additional patch data.
> 
> The patch stack is stored as a set of patches inside a directory, and 
> rebased using quilt.
> 
> An alternate representation stores the patch stack as a branch that is 
> rebased using git, and then exported to single files.
> 
> The Debian changelog is stored as a file inside Git, but some automation 
> exists to update this from Git commit messages.
> 
> Debian changelog entries refer to bugs in the Debian Bug Tracking 
> system. There is a desire to also incorporate forges (currently, GitLab) 
> and refer to the forges' issue tracker from commit messages (where the 
> issue tracker is used for team collaboration, while the Debian BTS is 
> used for user-visible bugs).
> 
> All of this is very silly, because we're essentially storing metadata as 
> data because we cannot express in Git what we're actually doing, and the 
> conflicting priorities people have have led to conflicting solutions.
> 
> I'd like to xkcd 927 this now, and find a common mapping.

Here's my very likely very naive 2 cents: we are basically maintaining a fork for each non-native package.

Being a fork, a "Debianized" package can also live like other "upstream" forks: with its own branch based on the original, make necessary changes and record them as commits; merge original onto its own branch, dealing with conflicts; maintain its own changelog; rinse and repeat.

Debian-specific metadata can be represented structurally in commit messages, or if necessary, (still) in a plain debian/ subdirectory that won't conflict with upstream.

Then,

Show 11 quoted lines

>  From a requirements perspective, I'd like to be able to
> 
>   - express patches as commits:
>     - allow cherry-picking upstream commits as Debian patches
>     - allow cherry-picking Debian patches for upstream submission
>   - generate the Debian changelog from changes committed to Git
>   - express filter steps for generating the upstream archive(s) from a 
> tree‑ish and some metadata
>   - store upstream signatures inside Git
>   - keep a history of patches, including patches applied to previously 
> released packages

these are naturally met; and

(...)

> Changes to packaging would still be represented as commit objects 
> containing a tree, but that tree would contain a special entry for the 
> "debian" subdirectory that points to the last packaging change.

no more needed.

Show 6 quoted lines

> This is very high-level so far, because I'd like to get some feedback 
> first on whether it makes sense to pursue this further.This would use 
> up the last unused three-bit object type in Git, so it will have to be 
> very generic on this side to not block future development -- and it 
> would require a lot of design effort on the Debian side as well to 
> hammer out the details.

Even less thought out, but probably easier to implement once the design is finished. ;)

-- 
Sdrager,
Blair Noctis