"Bastien Roucariès" <roucaries.bast...@gmail.com> writes: > Doing some code review on mozilla I found this interesting file > https://sources.debian.org/src/firefox- > esr/78.13.0esr-1/js/src/frontend/BinASTEnum.h/?hl=1#L1
> // This file was autogenerated by binjs_generate_spidermonkey, > // please DO NOT EDIT BY HAND. > I think we should warn level pedantic when we found this 'file (was|is) > autogenerated' and Do not edit by hand > It will help work of ftpmaster BTW I know that Lintian is the tool that we have and thus the easiest place to add this, and I'm not objecting to that to be clear. But, in the long run, I wonder an override is the best place to gather and store this information. Your immediate goal is to ask maintainers to check that every generated file does have source in the package (and ideally is regenerated during the package build). But it would also be useful to have a place to document where that source *is*, and possibly flag whether or not the work to regenerate it during the package build has been done. This make me think the ideal way to store that information would be in a separate YAML (or some similar format) file that documents derived sources included in the source package and where they came from. The Lintian check could then look for derived sources that aren't documented there and warn about them, without then responding to those warnings by putting structured data into the overrides file. This also provides a possibly smoother rollout strategy: any maintainer can opt in to documenting their derived source by creating that file, and if the file exists Lintian could be more aggressive about warning about derived source because it knows a maintainer is already intending to do so. It also opens up the possibility of interesting integrations with other tools; for example, dh_clean could automatically remove generated sources that are marked as regenerated in the build system, which would save some mucking about with manual configuration (but dh_clean wouldn't want to have to look at lintian overrides to find that information). Again, this isn't an objection to your proposed deployment strategy or the Lintian check as you proposed it, which is much simpler. Just a possible alternative approach that would give us richer package metadata in the long run and avoid carrying lots of mostly unstructured overrides indefinitely in favor of documenting these files in a format designed to do so. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
