Thanks a lot for the detailed review and suggestions — they are very
helpful to me.

I also learned quite a few packaging and maintenance practices from your
comments, including tools like myrepos and some of the usual Debian
packaging workflows that I was not yet familiar with.

I will go through the maintenance/update scripts again and
simplify/reorganize them according to your suggestions. I am also fine with
maintaining this in shell/make instead of Python; I do not want my own
tooling preferences to make future maintenance harder for you or other
maintainers.

I will also rework and rebase the git history so the commits become more
semantically atomic and easier to review.

Thanks again for taking the time to explain all this in detail.

On Wed, May 13, 2026 at 2:19 AM Jonas Smedegaard <[email protected]> wrote:

> 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

Reply via email to