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

[David Brownlee <abs%netbsd.org@localhost>]

On 13 December 2010 11:16, Julio Merino <jmmv84%gmail.com@localhost> wrote:
>
> I definitely do not want the configuration file within pkgsrc. ÂI do have
> several pkgsrc trees in my machine (for different reasons) and I want all of
> them to use the exact same configuration if at all possible. ÂI also want my
> source trees to remain clean of local changes, and adding a local file (be
> it checked in or not) breaks this rule (you'll get M or ? from cvs
> respectively).
>
> That said, I see why one would want to have a pkgsrc.conf file within
> pkgsrc.
>
> What about going from most specific to most generic, in order:
>
> 1) Source pkgsrc.conf from within pkgsrc if it exists; stop if found.
> 2) Source pkgsrc.conf from PKG_SYSCONFBASE if it exists; stop if found.
> 3) Source mk.conf if all above fails for compatibility reasons. ÂSpit out a
> warning in this case about possible future deprecation.

bmake (or NetBSD make) is going to source the current {PREFIX,}/etc/mk.conf,
unless we change existing behaviour (which I don't think we should do). I *do*
like the 1) or 2) options...

> With the above, a user can just create a pkgsrc.conf within pkgsrc if he
> wants to and he can choose whether he wants to fall back to 2 or not (e.g.
> depending on whether he does ".include ${PKG_SYSCONFBASE}/pkgsrc.conf" or
> not).

That certainly works for me :)

On 13 December 2010 04:10, Aleksej Saushev <asau%inbox.ru@localhost> wrote:
> David Brownlee <abs%netbsd.org@localhost> writes:
>
>> Hijacking this across into the sub thread with my updated proposal.
>>
>> 2010/12/12 Aleksej Saushev <asau%inbox.ru@localhost>:
>>> David Brownlee <abs%netbsd.org@localhost> writes:
>>>
>>>> On 11 December 2010 23:59, David Holland 
>>>> <dholland-pkgtech%netbsd.org@localhost> wrote:
>>>>> On Sat, Dec 11, 2010 at 08:14:26PM +0000, David Brownlee wrote:
>>>>>  > - Switch from mk.conf to pkgsrc.conf
>>>>
>>>> A file under PKGSRCDIR would make me happy - I'm less concerned about the 
>>>> name
>>>
>>> I don't like it under PKGSRCDIR, it doesn't belong there.
>>> I can (and I do) have several pkgsrc trees in the same file names space
>>> operating fine with the same LOCALBASE using the same mk.conf.
>>> mk.conf belongs to deployment not the pkgsrc tree.
>>>
>>> I don't think that $(TOP)/mk.conf is good idea either.
>>>
>>> BTW, same should apply to pkgchk.conf, perhaps I should file PR on that.
>>> It is annoying that pkg_chk defaults to configuration and cache/index files
>>> in PKGSRCDIR.
>>
>> I think we have conflicting requirements here - (as I understand it) you 
>> would
>> want any "pkgchk.conf" or similar to be shared across pkgsrc trees, as you
>> would want for any pkg_chk.conf or similar files, while I want them to be
>> pkgsrc tree specific. I specifically don't want to go messing around in 
>> mk.conf
>> when I switch to a different pkgsrc tree.
>
> All paths in pkgsrc tree are relative, thus when you work inside the tree,
> you work with current tree and everything is fine.
>
> If you have to pass path to pkgsrc tree to some tool, e.g. revbump, you just 
> do it.
>
> If you still need absolute path to pkgsrc tree, you're most likely playing 
> tricks,
> but then you have to know what you do anyway.
>
> One of such cases is when you're doing something like
>
>  .if $(.CURDIR) == "$(HOME)/pkgsrc-local/category/package"
>  CFLAGS+= -fsomething-evil
>  .endif

For that would you just not use PKGPATH? Or testing against
${PKGSRCDIR} if a absolute path is needed? I'm sorry, I don't see how
that relates to renaming or moving mk.conf?

>> I'm assuming if they lived under PREFIX that would be no better for you?
>>
>> What do you think about an environment variable which sets the basedir that
>> contains the config files (pkg_chk.conf, "pkgsrc.conf", and anything else
>> similar), though it may just be enough to specify it for "pkgsrc.conf" and
>> rely on values being set in there to affect everything else.
>
> No, it would be much better to me if configuration files that relate to
> _installation_ go along with installation, that is if they live inside
> prefix or related sysconfdir.
>
> To make it clear to others, pkgsrc tree is independent of installed packages.
> You can share it between different prefixes or you can use multiple trees
> to work on packages within the same prefix. Unless you're playing tricks,
> prefix is determined by installed binaries, it isn't remembered anywhere
> in pkgsrc tree, and path to pkgsrc tree isn't remembered anywhere inside
> prefix either. This gives you freedom to move pkgsrc tree around and to
> build packages for several installations using the same tree.
>
> On moving mk.conf.
>
> The most reasonable approach I can come up, is installing default /etc/mk.conf
> with this content:
>
> .ifdef BSD_PKG_MK
> .sinclude "/usr/pkg/etc/mk.conf"
> .else
> # Put your non-pkgsrc configuration here.
> .endif

but that is encoding an arbitrary PREFIX path in a global config file,
and breaks having multiple active PREFIXes on a given machine.

The only sane locations for pkgsrc config is under PREFIX or
PKGSRCDIR, and it should be a *pkgsrc* config file, specific to
pkgsrc, not a generic bmake config file.