> Prior to that we see warnings like this: > > /home/rekado/dev/gx/branches/master/gnu/packages/cran.scm:36350:2: > r-readtext: updating from version 0.82 to version 0.90... > /home/rekado/dev/gx/branches/master/gnu/packages/cran.scm:36350:2: warning: > r-readtext: no `version' field in source; skipping > > It’s as if the position in the file has been lost and it tries to update > the definition of r-readtext that is no longer where the current port > position is.
It seems that this is indeed the problem. The value for a <package>’s “location” field is known at compile/eval time and this value will not be correct after the first substantial edit has taken place. I see these options: 1 - pass a value to “update-package” that corresponds to line changes so far and let it return an updated value, making “update-package” aware of file changes. This would be rather ugly. 2 - compute the location of the target package anew if the file it is located in has since been edited. 3 - never rely on the line number of the package location value; just open the specified file and always search it for a package definition. Optionally take the line number into account as a starting point for a search in both directions. 4 - integrate changes with git, so that all edits are commits that are applied to the very same base commit. The third option seems the most reasonable and lightweight to me. -- Ricardo
