Hi Ludo, On lun., 27 févr. 2023 at 15:09, Ludovic Courtès wrote: > However, as I explained before, there’s no clear way to do that for two > reasons: > > 1. Transformations apply to bags, not packages, so we cannot tell > whether a transformation has an effect until after the transformed > package has been lowered. Even then, it’s tricky. > > 2. In this case, this has to do with the semantics of transformations > themselves: by definition, ‘with-source’ dismisses patches. I probably miss many details and that’s why I do not understand correctly your words. Or maybe we are not using the same meaning behind “report if the transformation makes sense or not”. 1. From my point of view, the transformations are functions that you compose. The composition rule is not commutative maybe neither associative. Writing down how each function (transformation) composes with the others allows to specify the composition rules. 2. All the code in (guix transformations) acts at the package level, so I am still missing why it would not be possible to detect some issues there. For instance, --8<---------------cut here---------------start------------->8--- (define applicable ;; List of applicable transformations as symbol/procedure pairs in the ;; order in which they appear on the command line. (filter-map (match-lambda ((key . value) (match (transformation-procedure key) (#f #f) (transform ;; XXX: We used to pass TRANSFORM a list of several ;; arguments, but we now pass only one, assuming that ;; transform composes well. (list key value (transform (list value))))))) (reverse opts))) --8<---------------cut here---------------end--------------->8--- and I miss why, 1. it would not be possible to check if the transforms compose well; somehow verify the assumption. For instance, ’package-with-upstream-version’ raises many warnings depending on various cases, and I miss why, 2. it would not be possible to have similar warnings for other transformations. Cheers, simon