On 2024-08-20 15:10, Simon Richter wrote: (...) > 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, > 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. > 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
Attachment:
pgpAR4q_2ongn.pgp
Description: OpenPGP digital signature
