Quoting Junyong Liang (2026-05-12 17:57:22) > Here is my repository: > https://salsa.debian.org/Junyong-Liang/hx > > My main contributions are: > > - adding a script to prepare the source package > - updating debian/copyright > > However, I am not fully sure whether some parts violate Debian Policy > or common packaging practices. Any feedback would be appreciated.
First of all: Thanks a lot! I have a tendency to highlight weak points and not mention the good stuff, so let me emphasize that no matter what I write below, I am super happy that you are looking into this, and I appreciate what you have done already. Even if you stopped now and just left your draft code behind, it would be a great help. Here are some quick notes, in random order, as I skimmed throught your changes: Please make atomic git commits. Specifically, add code separately from updating debian/copyright about the added code, and please don't update debian/copyrigt_hints at all - that is most sensibly done just before a release together with the final commit changing debian/changelog. If you suppress lintian warnings, then add a comment explaining your reasoning for doing so. You have added a copyright notice for an Erlang grammar to hx package. That looks wrong - and again it would help to understand the intent if git commits represent semantically atomic changes: Each commit does some meaningful change to the package (rather than each commit representing a history of all-at-once moves). I.e. use rebase to reshape git commits to each make sense. The script update-highlight-core seems to contain duplicated data - e.g. CORE_GRAMMARS in debian/rules (and in debian/core-langs.txt too?), and the get_version function already implemented in dpkg by doing "include /usr/share/dpkg/pkg-info.mk" in debian/rules. The debian/*.install files seem auto-generated, and if so would likely be more sensibly handled in debian/rules by calling dh_install with appropriate options. The script update-highlight-core does a *lot* of git clone operations. That is more efficiently done using myrepos. The cloned code is placed in Xhighlight-* dirs. I think it is more sensible to instead place it somewhere below debian/ - e.g. in debian/vendor/ - which is also much simpler to handle - no custom tarballs to generate. A directory ../.grammar-cache is created *outside* the package root. That's very naughty, and should *not* be done: It should be expected that package build routines do not interfere with the outside system! The script update-highlight-core seems over-engineered. I wonder if better implemented as one or a few shell scripts, executing those and other commands directly from debian/rules: Since debian/rules is a make file, it is by design good good at executing commands, check if they fail and print how they were called - which it seems the python script spends a lot of tedious lines implementing. Hope these comments are helpfull. Don't see them as things that are "wrong" and must be changed, but more things that I would be uncomfortable leaving as-is if I were to maintain it - partly because I am fluent in shell and make but not so fluent in python, where you seem more fluent in python. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
