Re: Moving mk.conf

[Julio Merino <jmmv%NetBSD.org@localhost>]

2010/12/13 Aleksej Saushev <asau%inbox.ru@localhost>:
> Please, try to understand this chain of choices and consequences that lead
> to selection of mk.conf:

I *seriously* doubt there was a chain of choices in "selecting"
mk.conf.  mk.conf has been there since before pkgsrc, so when pkgsrc
came in it was the most convenient place in which to put configuration
in... and it stayed, for better or worse.

[...]
> 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.)

All you wrote above describes *how* things work today, not how the
current mechanism is better/clearer than anything else.  To me, it's
anything but an artifact of the past.

> 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.

... and is that really a good thing?  A configuration file ought to be
that, a configuration file, not something that can do who-knows-what
and end up screwing up your framework.  (Been there, done that.)

> 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".

No, that's conceptually wrong.  make doesn't have a "configuration" --
actually, it *shouldn't* have one in pkgsrc's context.  In pkgsrc, all
you configure in mk.conf is how pkgsrc/mk/ behaves, not how make
behaves.  These are two *very* different things.

> Note that location and layout of installed packages is determined by make 
> binary,

Nope; the make binary does not determine anything.  It's the make
scripts who do, and those live in pkgsrc, are pkgsrc-specific and
could be potentially configured in any separate way you could imagine.

[...]
> 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

That does NOT count as easy.  It is just an ugly *workaround* for the
fact that mk.conf can be used for an arbitrary variety of things.
Remember: it was never designed to be pkgsrc's configuration file, it
just came to be.  And also, the fact that pkgsrc uses make is an
implementation detail; henceforth, having to "configure" pkgsrc in
mk.conf is misleading.

Just consider this: you go and create a new FooBar project on
sourceforge and, for that project, you decide to use NetBSD's make.
Your Makefiles support some special configuration variables to tune
the configuration of FooBar, so you document them.  When someone asks
if the values of such configuration variables can be made persistent,
you realize that mk.conf exists and you tell them to put the stuff in
the file, only to later realize that your special configuration
variables (BINDIR?) collide with the native variables used by NetBSD
*.mk files or the variables of pkgsrc.  Now what?  You introduce a
BSD_FOOBAR_MK variable to prevent this collision and your mk.conf
becomes a complicated mess of ifdefs to cope with different projects.
That seems like a pretty ugly thing to me, but guess what, is what
pkgsrc is doing.

> E.g. the pkgsrc guide, 3.3.6, only it is applied to OpenBSD there.
>
> What exactly is the problem with the above??

That it's not the best possible solution, that it is confusing and
that it can easily have nasty side-effects that break things
mysteriously.

> 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?

I doubt it's that hard.  We control *both* pkgsrc and make/bsd.own.mk
so we can surely think of a way to make things work.  One possibility
could be to just make pkg_install expose the name or directory of the
configuration file (/etc/foo in NetBSD, ${PKG_SYSCONFDIR}/foo in
bootstrapped systems).

-- 
Julio Merino