Re: pkg/53867 (lang/erlang-doc fails after update)

["David H. Gutteridge" <david%gutteridge.ca@localhost>]

The following reply was made to PR pkg/53867; it has been noted by GNATS.

From: "David H. Gutteridge" <david%gutteridge.ca@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: leot%netbsd.org@localhost
Subject: Re: pkg/53867 (lang/erlang-doc fails after update)
Date: Mon, 25 Mar 2019 09:18:41 -0400

 On Mon, 2019-03-25 at 11:30 +0000, Leonardo Taccari wrote:
 > The following reply was made to PR pkg/53867; it has been noted by GNATS.
 > 
 > From: Leonardo Taccari <leot%NetBSD.org@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc: 
 > Subject: Re: pkg/53867 (lang/erlang-doc fails after update)
 > Date: Mon, 25 Mar 2019 12:26:25 +0100
 > 
 >  Hello David,
 >  
 >  David H. Gutteridge writes:
 >  >  [...]
 >  >  I think the best way to handle this is to use a dynamic PLIST for those
 >  >  parts of the package that have regularly-changing version numbers
 >  >  embedded in their paths. We can't rely on the equivalent versions in
 >  >  lang/erlang, as they may vary between the packages. I borrowed from the
 >  >  same approach used in databases/couchdb (which deals with the same
 >  >  problem). The remaining PLIST file would be accordingly pruned to just
 >  >  the entries that aren't part of the dynamically generated list.
 >  >  [...]
 >  
 >  If that's the case why not avoid using ${VERSION.*} variables in
 >  lang/erlang-doc/PLIST? (i.e. always unconditionally expand the
 >  values of them?)
 
 Basically, I was trying to follow a similar approach to what the
 maintainer (fhajny@) had already used in a related package (databases/
 couchdb), which is where I took that snippet from. It may be less
 necessary here than there, but it seemed (to me) in keeping with the
 style used in other Erlang-related packages.
 
 (Part of what I took that style to be being: the desire to reduce the
 amount of mechanical work needed every time a series of related
 packages are updated. This is a broader topic, e.g. jperkin@ brought up
 a different kind of example of this in PR pkg/53975 recently, within
 one package, where there is a lot of conditional content that kept
 getting lost on updates.)
 
 If the preference is to do it the simpler way, with a manual PLIST, I'm
 not going to argue about it. It would be nice to close the PR, either
 way. :)
 
 Dave