Re: Moving mk.conf

[Aleksej Saushev <asau%inbox.ru@localhost>]

David Brownlee <abs%netbsd.org@localhost> writes:

> On 13 December 2010 04:15, Aleksej Saushev <asau%inbox.ru@localhost> wrote:
>> Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost> writes:
>>
>>> On 12.12.2010 22:45, David Brownlee wrote:
>>>> 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
>>>> 'pkgsrc.conf'
>>>>   or 'pkgsrc.mk' to 'pkgsrc.mk.conf' but I'm happy to go with consensus.
>>>
>>> Same goes for me. I am not too concerned by the name, so long it fits
>>> the (silent) majority.
>>
>> I object to renaming. It is cosmetical change of dubious value.
>
> Its definitely not cosmetic - its functional. Its putting pkgsrc build
> config into
> a specific pkgsrc config file, not putting it in a generic bmake
> config location.

It's becomming tiresome. :)

Please, try to understand this chain of choices and consequences that lead
to selection of mk.conf:

1. All pkgsrc is built around bmake, which is called "make" in NetBSD base.
2. bmake has its own configuration directory, which is set at build time.
   It differs between NetBSD base make and pkgsrc built bmake.
   See make(1) or bmake(1), "-m", MAKESYSPATH.
3. This directory contains <bsd.own.mk>
4. <bsd.own.mk> sets default MAKECONF value.
   See pkgsrc/pkgtools/bootstrap-mk-files/files/mods/bsd.own.mk.in
5. Default MAKECONF points to mk.conf, which is /etc/mk.conf when NetBSD
   base make is used.
6. When using pkgsrc built bmake, mk.conf provides all necessary paths that
   point outside pkgsrc tree, LOCALBASE, PKG_SYSCONFDIR, VARBASE, PKG_DBDIR,
   HOMEBASE, DISTDIR, PACKAGES, and so on.
   All these variables have respective "sane defaults", the one you're
   using on NetBSD, the one built into binary packages you install with
   pkg_add on fresh system.
   Note that in presense of several bmake instances, because of 1-4,
   all these variables are determined by bmake instance currently running.
7. pkgsrc tree itself doesn't depend on its absolute location, all paths
   inside pkgsrc are relative. By default, you can move it freely around.
   You can remove it and extract it again, at the same location or at
   another one. This also gives system administrator freedom to devise
   more complex strategies to maintain complex installations.
   (Note that NetBSD src and xsrc maintain the same property.)

You can see that it is already complex process, that provides several
consistent settings and consistent behaviour not only on NetBSD, on other
platforms too. bmake isn't pkgsrc-only tool, you can use it for your own
purpose, and you can do it with success not only on NetBSD.
bmake is general-purpose tool.

Because bmake is make, you can do in mk.conf more complex things than
just setting variables. Alistair gives you example how you do it.
If you search through archives, you'll find other examples of people
using this feature that bmake is make and pkgsrc configuration is
configuration of its make tool. This one of reasons why it is "mk.conf"
and not "pkgsrc.conf".

Note that location and layout of installed packages is determined by make 
binary,
not by pkgsrc tree. If you tie pkgsrc tree to layout of installed packages,
you break all useful properties of this independence. See p.7 above.
If you tie them up, you'll make it hard to remove pkgsrc tree and only
extract it on demand. Or to move it away. Or use modified tree to
install into different place for testing purpose.

The only problem is that on NetBSD base make is at the same time pkgsrc make.
Here two large and complex build systems, pkgsrc's and NetBSD's, intersect.

By this time, the separation of pkgsrc and NetBSD can be done easily,
the pkgsrc guide tells you that you should protect pkgsrc specific settings
with BSD_PKG_MK:

    .ifdef BSD_PKG_MK
    # pkgsrc stuff
    .else
    # other stuff
    .endif

E.g. the pkgsrc guide, 3.3.6, only it is applied to OpenBSD there.

What exactly is the problem with the above??
What exactly should be fixed and what are _realistic_ ways to do that?

You propose to split the pkgsrc and base configuration parts into
separate fils. How exactly are you going to do that?
You see above that pkgsrc configuration part is determined by make
instance. So is base configuration part. They intersect essentially.

There are ways to separate them, but they are not what you propose.
One way is to make them different tools like it is done on DragonFly.
But Dragonfly has more reasons to do that since their base make is
FreeBSD make which isn't compatible with NetBSD make enough.
Another way is to force all users to pass explicit MAKECONF when working
with NetBSD source or pkgsrc (or with either).

The most realistic and the most convenient way so far is to install
default mk.conf that suggests correct way to configure both.
It is possible to use /usr/pkg/etc/mk.conf as a place for separate
pkgsrc-specifig part, because this is its place, if you bootstrap.
And this is the best way so far. At least I don't see any other
alternatives that don't break already established practice.


-- 
HE CE3OH...