Re: pkg/45136 ([MAINTAINER][PATCH] www/aws, fix DESTDIR breakage and other problems)

[John Marino <netbsd%marino.st@localhost>]

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

From: John Marino <netbsd%marino.st@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: OBATA Akio <obache%netbsd.org@localhost>, pkg-manager%netbsd.org@localhost, 
 gnats-admin%netbsd.org@localhost, pkgsrc-bugs%netbsd.org@localhost
Subject: Re: pkg/45136 ([MAINTAINER][PATCH] www/aws, fix DESTDIR breakage
 and other problems)
Date: Mon, 25 Jul 2011 11:42:54 +0200

 On 7/25/2011 11:05 AM, OBATA Akio wrote:
 > On Sun, 24 Jul 2011 23:40:03 +0900, John Marino <netbsd%marino.st@localhost>
 > wrote:
 > 
 >> "Why do you want to use dynamic GENERATE_PLIST?" The answer is WAY
 >> more complicated than a simple pdf option.  Believe me, I had good
 >> reason to remove the existing static list and replace it with the
 >> dynamic one.  The number of permutations of files with the entire
 >> set of options is large, and using a static list is prone to error.
 >> Without going into a lot of detail, it would be best to accept that
 >> a dynamic PLIST is the way to go here, which will always be
 >> correct.  The existing PLIST isn't "correct" minus pdf either, it's
 >> going several existing problems with it.
 > 
 > At least, some of files in your GENERATE_PLIST (ex. bin/aws_password,
 > and so on) no need to be generated dynamically, so you can put those
 > files in static PLIST. If some conditionally installed files are
 > large set, you can put those files in  separate PLIST.* files and add
 > those file names to PLIST_SRC conditionally.
 > 
 > Disadvantage of full dynamically PLIST generation are:
 > 
 > * We cannot track changes of installed files between version up of
 > the package * We cannot confirm what files will be installed before
 > trying to install the package * We cannot catch up accidental
 > mis-installation, say, "some required files are not installed", or
 > "some redundant files are installed".
 
 I was not aware that static PLIST file can be used with dynamically
 generated PLIST.  I thought it was one or the other.
 
 Clearly GENERATE_PLIST exists for a reason.  Can't we just accept the
 disadvantages (only the third one catches my interest at all) to close
 out this tested iteration?  On the next update, I can move some of these
 into a static PLIST (PLIST + GENERATE_PLIST = complete PLIST?)
 
 Regards,
 John