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