pkgsrc-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/48110 (PKG_DBDIR in /etc/pkg_install.conf is ignored by pkgsrc make)
The following reply was made to PR pkg/48110; it has been noted by GNATS.
From: Aleksej Saushev <asau%inbox.ru@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc:
Subject: Re: pkg/48110 (PKG_DBDIR in /etc/pkg_install.conf is ignored by pkgsrc
make)
Date: Tue, 13 Aug 2013 01:53:48 +0400
Toby Karyadi <toby.karyadi%gmail.com@localhost> writes:
> What I really like about pkgsrc is the ability to cleanly separate the
> base stuff (whatever comes with netbsd) and the other stuff, no
> intermingling in /usr/bin/, /usr/lib, what have you. I'd like to be able
> to just delete /usr/pkg and you're back with a base OS, or at least
> close to it. By having the pkg db in the same dir as the installation
> directory I can better ensure that pkg_info is telling me an accurate
> answer.
>
> Another use case that I can think of would be to have different pkgsrc
> installation directories, e.g. /usr/pkg0, /usr/pkg1, /usr/pkg-broken,
> /usr/pkg-testing, what have you, and have /usr/pkg as a symlink to one
> of those. By keeping the pkgdb with the installation dir, it would allow
> for quickly switching between different pkgsrc installation sets. I
> haven't actually tried this, but there shouldn't be any reason for it to
> fail. I faintly remember something about pkg views which might do the
> same thing, but I haven't look much into it.
> The way I see this issue is more like value inheritance in the hierarchy
> that starts with pkg_install.conf (for the pkg_*) at the base, that can
> be overriden at the mk.conf level (for the pkgsrc build), and finally
> can be overriden at the environment variable level. Note, that at any of
> those levels it should be possible that the value override is equal to
> the default value, but it should tell the machinery that I really want
> to use that value at that particular level.
>
> Since pkgsrc build machinery should logically use pkg_install and
> pkg_delete, and actually is, I was really surprised that it didn't take
> the specific setting from pkg_install.conf. So, it's more of an
> unexpected behavior. If no change is going to be done, at least the
> documentation should give a warning.
Build machinery shouldn't consult binary tools, it breaks separation between
build machinery and binary installation machinery. pkg_install.conf has
nothing to do with build mechanics. Therefore there's nothing surprising that
pkg_install.conf settings are ignored by bmake. In fact, it would be
more surprising if they weren't.
"bootstrap --prefix /usr/pkg-something --pkgdbdir /usr/pkg-something/pkgdb"
(or even "bootstrap --prefix /usr/pkg-something --varbase
/usr/pkg-something/var")
does all what you want and more. Use corresponding bmake and pkg_install tools,
and you have different "installations" at once, you don't even need playing
with symlinks (though this depends on whether you're capable of remembering
what your symlink points to today, personally, I usually recommend not to rely
on human memory for this, unless you're doing more meaningful manipulations,
like switching between pkgsrc branches or larger projects).
--
BCE HA MOPE!
Home |
Main Index |
Thread Index |
Old Index