Marius Bakke skribis: > Marius Bakke writes: > >> Ludovic Courtès writes: >> >>> Marius Bakke skribis: >>> >>>> After patching 'notmuch', `guix lint -c patch-file-names` does not pass >>>> for 'python-notmuch' which inherits the source from 'notmuch'. >>> >>> I agree but that’s not quite possible: the “inheritance” relation (which >>> is really just a copy of a record) is not known at run time. >>> >>> So we’d need another trick to guess whether a patch is coming from >>> elsewhere and should consequently be ignored by ‘lint’. >> >> Here is a "RFC" patch that thwarts the warning if the source file name >> is different from the package name. Not sure how to properly make it >> part of the procedure, so that the checks are actually skipped as well. > > I just realized this approach will skip this check completely, if there > are no packages that are named the same as origin (e.g. in the case of > the soon-to-be-added avro, where the source is shared between the > various avro-{c,python,java} etc packages.) > > The best approach is probably to check patch-file-names against > (origin-actual-file-name (package-source package)), assuming one can > extract the "base" name of origin-actual-file-name reliably. (‘origin-actual-file-name’ already returns a basename.) Could you check whether the patch your proposed works well for some of the annoying cases we currently have, and also adds those as test cases in ‘tests/lint.scm’? (See the manual on how to run the tests (info "(guix) Running the Test Suite").) If that works well enough, we should go for it. The only 100% reliable way to address this, I think, would be to build a patch to package mapping, and then make sure that for each patch, at least one of the corresponding packages has a matching name. The problem is that ‘lint’ is currently designed to work one package at a time. Thanks! Ludo’.