tech-pkg archive

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

Re: Moving mk.conf (Was: Making it easier to get and use pkgsrc)

(Split just one part out from the thread to try to get a resolution)

On 12 December 2010 11:51, Jean-Yves Migeon <> 
> On 12.12.2010 00:59, David Holland wrote:
>> On Sat, Dec 11, 2010 at 08:14:26PM +0000, David Brownlee wrote:
>> > - Switch from mk.conf to pkgsrc.conf
>> I'm not sure this is a good idea. On the one hand, it avoids needing
>> the magic knowledge that pkgsrc is make-based; on the other hand, you
>> have to know that to do anything with pkgsrc. I think if we're going
>> to move to something that advertises itself specifically as pkgsrc
>> configuration that it should be restricted to configuration statements
>> that make sense for pkgsrc and not necessarily be an arbitrary make
>> fragment... but that would cause regressions if we aren't careful.

Unfortunately in some situations you need just that ability to include
arbitrary make logic in this file. My contention is that it should not
be in /etc, and it should be a file which is only included by pkgsrc,
not by a standard bmake running on the system.

> Then call it instead of pkgsrc.conf?
>> However, I do tend to think that things should be self-contained and
>> that the *base system*'s build should use $(TOP)/mk.conf (or maybe
>> $(TOP)/, but within the tree) rather than a file in /etc.
> Separate issue.

Separate but related. If you're looking to change a file for two
different reasons
then its better to change it once than twice (assuming people agree that both
changes are worthwhile).

So, updated proposal:

- Create a pkgsrc.conf which is included by pkgsrc similar to mk.conf.
  The intention is that it will be included as well as any system etc/mk.conf,
  but will only contain pkgsrc related make directives, not anything which
  would affect standard bmake (or 'make' in NetBSD) calls. I prefer
  or '' to '' but I'm happy to go with consensus.
- This file to checked for inside PKGSRCDIR, and can be overridden by an
  environment variable. I would prefer an etc or conf directory inside
  PKGSRCDIR rather than continuing to populate the top level directory with
  config files a'la pkgchk.conf etc, but that is probably more because I would
  want to keep my copy under a separate RCS, and thats an awful lot easier
  in a subdir (and I can use a symlink anyway).

Home | Main Index | Thread Index | Old Index