tech-pkg archive

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

Re: Moving mk.conf

On Mon, 13 Dec 2010 20:10:22 +0300, Aleksej Saushev <> 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 <>. 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"

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

Home | Main Index | Thread Index | Old Index