Re: Moving mk.conf

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On Mon, 13 Dec 2010 20:10:22 +0300, Aleksej Saushev <asau%inbox.ru@localhost> 
wrote:
> > This is wrong: mk.conf relates to pkgsrc, not system package
> > configuration directory.
>
> mk.conf relates to package configuration directory.

And that's supposed to be /etc?

I wonder why /usr/pkg/etc/mk.conf gets used for bootstrapped pkgsrc 
then...

> > BTW, that's dubious, you hardcode path to /usr/pkg (which is
> > completely arbitrary, so how is it supposed to work when someone
> > bootstraps with a different --sysconfdir?)
>
> You don't understand how pkgsrc works then.

Of course I don't. This /etc/mk.conf thing is one of those few that I 
really cannot understand. Especially when pkgsrc is expected to be "self 
contained", but where its behaviour depends on a file found under /etc/, 
while bootstrapping "moves" it to sysconfdir/.

> pkgsrc tries hard to isolate
> packages and itself from anything outside base system and prefix.
> ("Oh, it's Solaris, sh is broken on Solaris, let's install pdksh...
> And sed is broken too, let's install nbsed...")

Well, that's the difference between having something that "justs works" 
and something that "may work, depending, you know, on the brokenness 
level of your base OS."

I can't see how having /etc/mk.conf helps here, especially when its 
content will have unforeseen consequences in case it gets modified by 
the base system (how is that "isolation"?)

> When you bootstrap pkgsrc, you build and install bmake.
> bmake knows location of its own configuration file, and it is package
> configuration directory. bmake's default configuration file sets
> LOCALBASE, PKG_SYSCONFDIR, VARBASE and other necessary variables.
> When you run specific instance of bmake, it sets all necessary paths
> that are outside pkgsrc tree, and all paths inside pkgsrc tree are
> relative and thus independent of pkgsrc tree location.

I feel awkward each time I read "make/bmake" configuration file. For 
what purpose an interpreter is supposed to have a "configuration file"? 
Mimic php? Throwing in some /etc/gcc.conf might be a good idea too...

/etc/mk.conf is not "bmake's configuration file", it relates to make(1) 
in a specific context: BUILDING(8). And I would expect the same for 
pkgsrc, however in pkgsrc's context.

> The only difference is NetBSD itself, which comes with bmake 
> preinstalled
> and under another name. On NetBSD bmake is called "make" and looks 
> for
> its configuration file in /etc.

See above. make only looks for /etc/mk.conf because he gets told to via 
<bsd.own.mk>. So why don't we get the same with pkgsrc?

> If we agree that /usr/pkg is default prefix on NetBSD, then it has to 
> be
> embedded somewhere. It is embedded into pkgsrc already (default 
> prefix),
> and in binary packages, which are built and shipped with default 
> options.
> I suspect that /usr/pkg is embedded into default login.conf or 
> profile too.
> Thus embedding default /usr/pkg in system's default is reasonable. It 
> is
> already spread over system configuration, doing it once more doesn't
> change much.
>
> > If you want to share a common core between multiple pkgsrc
> > setups, just have PKGSRCDIR/conf/mk.conf (whatever its name,
> > just put it below PKGSRCDIR), and .sinclude /etc/mk.conf (which
> > can be done by added by default, if you want to.
>
> This is overly complex and error-prone, it works much better already.

Please explain why you find:

.if exists(/etc/mk.conf)
.sinclude "/etc/mk.conf"
.endif

in "pkgsrc.conf" overly complex and error-prone for NetBSD. You are 
still free to set whatever variable for BSD_PKG_MK in /etc/mk.conf, and 
have self-contained mk.conf for a given pkgsrc tree.

> > All paths in pkgsrc are relative. It's not obvious that its
> > behaviour can depend on a file living _outside_ its base dir. I
> > hardly cannot see the reason why it was made that way by default
> > with NetBSD...
>
> When you bootstrap pkgsrc you explicitly set some parameters that 
> point
> outside pkgsrc.

And IMHO, that should also be the case with /etc/mk.conf.

> When you install package, you use tools that exist
> outside pkgsrc tree. It is done this way already, and there's 
> absolutely
> no need to change it. It provides enough flexibility for more complex
> administration and development patterns than using single central 
> tree
> and single central prefix for packages.

I am not talking about package installation, but package build.

Anyway, I believe that the problem lies in the fact that pkgsrc is not 
bootstrapped for NetBSD (at least, in the most encountered case).

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost