--+ZmrHH5cGjskQnY1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 22, 2004 at 11:10:41PM +0200, Julio M. Merino Vidal wrote:
  | On Thu, 22 Apr 2004 21:49:08 +1000
  | Luke Mewburn <lukem@NetBSD.org> wrote:
  |=20
  | > Why not unconditionally install all SUPPORT_FILES and
  | > conditionally (based on PKG_CONFIG!=3DNO (?)) install CONF_FILES.
  | >=20
  | > Otherwise, what's the effective difference between CONF_FILES
  | > and SUPPORT_FILES, other than the variable name?
  |=20
  | Quoting bsd.pkg.install.mk:
  |=20
  | # CONF_FILES are pairs of example and true config files, used much like
  | #       MLINKS in the base system.  At post-install time, if the true c=
onfig
  | #       file doesn't exist, then the example one is copied into place. =
 At
  | #       deinstall time, the true one is removed if it doesn't differ fr=
om the
  | #       example one.  SUPPORT_FILES is used the same way, but the packa=
ge
  | #       admin isn't prompted to customize the file at post-install time.
  |=20
  | I guess there may be some situations where it may be interesting to use
  | SUPPORT_FILES to install files under PKG_SYSCONFDIR... or maybe not... =
so
  | enabling their installation unconditionally doesn't seem TRT (WRT PKG_C=
ONFIG
  | semantics) :P

I saw that in the documentation.

I still don't understand the point of SUPPORT_FILES versus CONF_FILES.=20
The current semantics of SUPPORT_FILES seem like
	"here's an admin modifiable config file (so we don't install
	it with PKG_CONFIG=3DNO) that we're not going to suggest to modify"
That seems ... pointless to me.

Obviously I'm missing something...

Cheers,
Luke.

--+ZmrHH5cGjskQnY1
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (NetBSD)

iD8DBQFAiDdmpBhtmn8zJHIRAozgAJ4jakuBc6vfkQnwLELYf10onhg3QgCdEpJg
708NzTHhv7eLBt/GIhLTf18=
=eTcW
-----END PGP SIGNATURE-----

--+ZmrHH5cGjskQnY1--