Hi, Le 2025-02-17 22:47, Julien Puydt a écrit :
Their .tbz is working nicely -- but it isn't source anymore!
I think that we disagree on this one. Here the extent of source code and build files changes between the .tbz and the git repository is reasonably small and can be compared to what happens in many projects where at release time a local release branch is created, variables and metadata are adjusted, the sources/binaries/docs distributions are built, and only the tag is pushed to the public repository. The issues I see in this project is that these changes are not committed to the git repository at all, and that using external templating to set a version number in so many different places is an antipattern. If you wanted to manually revert these changes to get the source tree in the same state as the upstream development branch, it would only take you a few minutes. If this really bothers you, you could also ship a diff in your debian source package, automate the update of said diff with a custom script run by uscan and document all that in d/README.source.
Here I would probably use the .tbz as I would consider it the preferred form of modification when it comes to fixing things in this version of the package (less steps and thus less risks that a later release of some build tool behaves differently and breaks things).
Cheers, -- Julien Plissonneau Duquène
