Subject: Re: Improving the "mail info on pkg install/deinstall" semantics ...
To: Luke Mewburn <lukem@NetBSD.org>
From: Johnny C. Lam <jlam@NetBSD.org>
List: tech-pkg
Date: 07/21/2004 05:03:39
On Wed, Jul 21, 2004 at 12:38:46PM +1000, Luke Mewburn wrote:
> 
> We need a more generic framework within pkgsrc to generate messages
> that will get added to the email to PKGSRC_MESSAGE_RECIPIENTS.
> (The latter variable might be renamed if this occurs, since it would
> be more encompasing than ``email the MESSAGE file'')
> 
> It looks like this feature request would require an overhaul of
> pkgsrc infrastructure.  Should I send-pr this?

Yes, please do, or add it to pkgsrc/doc/TODO.  Either way, this is
something that shouldn't get lost in the noise on tech-pkg.  Even if
it does require an overhaul, this would be a good thing to have.

> (I have considered removing PKG_CONFIG=NO if I can be confident
> that it won't screw me again when I have my own config files
> that incorrectly got replaced by the "default" configs which
> once occurred with samba, leaving my samba shares "wide open"
> with the default smb.conf until I noticed the problem.)

I think this was a problem of poor release management (on my part,
and I own up to it).  The incident to which you are referring probably
was due to net/samba changing where it looked for it's config files
when it was converted to honor PKG_SYSCONFDIR.  I should have preserved
the old default for samba's config directory for a while until users
caught up with and understood the ramifications of the latest changes.

I do note, however, that if a directive to make the appropriate changes
to your config was added to the MESSAGE file and was some how mailed
to you as your suggested framework would allow, that this problem
would have had a much lower chance of rising up to bite you.  Having
the framework would provide one more solid communication pathway
between pkgsrc developers and users that would be simple to use.  This
is just one more good reason to implement the framework.

	Cheers,

	-- Johnny Lam <jlam@NetBSD.org>