On Nov 4, 2018, at 16:27, Helmut K. C. Tessarek wrote:
> On 2018-11-04 02:49, Ryan Schmidt wrote:
>> The way I would approach this is to write a patch file which inserts
>> "@VERSION@" into the file where you want the version to appear. Then
>> you can simply reinplace "s|@VERSION@|${version}|g" to get the real
>> version into the file. That's very simple to understand and it's a
>> pattern we use in many other portfiles to insert the prefix or other
>> portfile variables.
>
> Yes, I thought about that. However, this means I have to create a new
> patch file every time there's an update to that line.
That's correct, and most of the time I think that's a good thing. Time and
again we see the problem that a port contains a reinplace, the port is then
abandoned and the next person to take up the port doesn't take the time to
fully understand all of the portfile, and then the port is updated to a new
version of the software in which upstream had changed the line(s) the reinplace
was supposed to affect in such a way that the regex no longer matches. This
used to be a silent failure, which depending on what the reinplace was supposed
to do could cause a build failure (which would be noticed) or the build might
still succeed but might be missing a vital change that causes the software not
to work correctly; this might not get noticed before being committed. We
finally got a warning added to MacPorts so that if a reinplace doesn't do
anything you're notified, but since it's just a warning it's often ignored. A
failing patchfile, on the other hand, is a hard error. The developer *must*
resolve it before they can reasonably commit the port. That's good. It forces
them to figure out what the patchfile was changing, figure out how to apply
that same fix to the new upstream source or else determine that the patch is no
longer needed and remove it.
-Ryan
