Hello Mark, Mark H Weaver <m...@netris.org> skribis:
> l...@gnu.org (Ludovic Courtès) writes: [...] >> Lesson learned: we should not rely at all on generated patches because >> they are bound to change frequently (version string at the end, length >> of commit hash prefixes, etc.) It’s probably worse than tarballs >> generated by Git hosting services. > > I guess the length of the commit hashes probably won't change very > often, so the version number is the most pressing issue here. Overall though such patches may typically change several times a year. > I wonder if it would be worth adding a special 'origin' type that > removes the version number from the end of git patches. As I replied to Maxim, this is not really possible. >> So we should probably work towards using local copies of patches, unless >> we find that the generated patches do not include any variable bits. > > It might still be best to work towards using local copies of patches, > although in the case of IceCat the set of patches is often quite large. > > Another issue to consider is that the use of local copies of patches > involves putting more trust in contributors, in practice, or at least it > seems so to me. When someone adds a non-obvious patch from upstream as > a local file, it leads me to want to check to make sure it hasn't been > modified from the upstream version, whereas if the package recipe > fetches a patch from a URL that is clearly from the upstream git > repository, it's somewhat more transparent what's going on. Yeah I agree with this. Another concern is unbounded growth of the Git repo. OTOH a patch that changes over time becomes non auditable: you’ll notice it has changed, and maybe that’s because of a benign change like those discussed above, but maybe it’s something else; if you can’t retrieve or reproduce the original patch, you can’t tell what the difference is. So I don’t have a good solution, but I think we should avoid upstream patches when we know they are generated in a non-reproducible fashion. Thanks, Ludo’.
