[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 <asau%inbox.ru@localhost>
This is wrong: mk.conf relates to pkgsrc, not system package
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
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
and under another name. On NetBSD bmake is called "make" and looks
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
embedded somewhere. It is embedded into pkgsrc already (default
and in binary packages, which are built and shipped with default
I suspect that /usr/pkg is embedded into default login.conf or
Thus embedding default /usr/pkg in system's default is reasonable. It
already spread over system configuration, doing it once more doesn't
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:
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
When you bootstrap pkgsrc you explicitly set some parameters that
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
no need to change it. It provides enough flexibility for more complex
administration and development patterns than using single central
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).
Main Index |
Thread Index |