Re: Moving mk.conf

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

Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost> writes:

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

Because that's how it is set in bsd.own.mk, see
pkgtools/bootstrap-mk-files/files/bsd.own.mk.in for details.

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

The problem is that on NetBSD pkgsrc isn't self-contained.
Part of pkgsrc infrastructure is embedded into NetBSD itself,
and there's strong resistance to move it out.

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

If package doesn't break rules, everything goes fine. If it breaks
rules, chances are that it breaks on one or another platform with
wide enough support. This gets noticed. In most cases it "just works,"
even on Solaris or HP-UX.

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

For what purpose do you use /etc/mk.conf? pkgsrc uses it for exactly the
same purpose, it customises builds.

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

Because pkgsrc built bmake provides another, its own set of bsd.*.mk files,
<bsd.own.mk> included.

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

This I don't understand. I have never said anything like this.

I find "pkgsrc.conf" change harmful, because it is cosmetic,
it hides the fact that this configuration file is in fact
interpreted by bmake, and at the same time it disrupts 
well-established practice for a very little gain, if any at all.
This issue is too convoluted already as you can see yourself,
there's no reason to make it worse.

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

Are you ready to follow DragonFly and use /usr/pkg/bin/bmake for pkgsrc work?
They have more reasons to do so, their FreeBSD make and NetBSD bmake
are not compatible enough.

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

To build a package you use pkg_create which belongs to pkg_install;
and unless it is very primitive package, you also use a whole bunch
of other tools (e.g. libtool and pkg-config) each sitting in pkgsrc
localbase rather than in pkgsrc tree or in base system.


-- 
HE CE3OH...