pkgsrc-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/45136 ([MAINTAINER][PATCH] www/aws, fix DESTDIR breakage and
 other problems)
Date: Thu, 28 Jul 2011 02:36:41 +0000

 On Mon, Jul 25, 2011 at 09:45:02AM +0000, John Marino wrote:
  >> * 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".
  >
  >  Clearly GENERATE_PLIST exists for a reason.  Can't we just accept the
  >  disadvantages (only the third one catches my interest at all)
 
 Being able to detect PLIST conflicts before it's too late is also
 worthwhile.
 
 And, one of the things that goes wrong sometimes is that destdir
 support turns out to be partial, so some files get installed to the
 destdir and some straight to /usr/pkg. Then the package appears to
 work fine... but if you pkg_tarup it or build a binary package and use
 that on another machine, it ends up being incomplete. This tends to
 interact poorly with the way many people handle production systems
 (build and test on a crash machine, then apply the binary package to
 the production machine) so we don't want to let it happen.
 
  >  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?)
 
 If it were me I'd probably go stuff in all the plist vars, but
 sometimes it really isn't worth it.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost
 


Home | Main Index | Thread Index | Old Index