[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>
Subject: Re: pkg/48110 (PKG_DBDIR in /etc/pkg_install.conf is ignored by pkgsrc
Date: Wed, 14 Aug 2013 21:14:45 +0400
Toby Karyadi <toby.karyadi%gmail.com@localhost> writes:
> I know, my prior example were contrived. My point is that if each pkg
> installation set is self contained, including the pkg db, and if
> pkg_install.conf is told to be a dir inside /usr/pkg, whatever you set
> the /usr/pkg symlink to would not matter, and all of the pkg_* tools
> would just work properly.
Currently, if you're using pkgsrc framework, it is expected, that your
binary tools are consistent with framework settings. In fact, if you use
the framework correctly, the latter defines everything (we even support
installation of newer pkg_install on NetBSD, if the base one is too old).
I don't think that it is practical to implement support for pkg_install
being hostile to pkgsrc, that's why (one of reasons) I argue that this
is not a bug.
> If the /usr/pkg is deleted, the pkg db will
> be automatically consistent with the fact that none of the pkgs is
If you delete /usr/pkg, you should delete pkgdb as well. You're expected
to reconfigure your system startup scripts yourself too, unless they are
tolerant to executables that disappear with removal of /usr/pkg.
It may be that you need to remove other binaries that reference libraries
from /usr/pkg/lib too. There's a lot of what you may need to do when you
remove anything from your system in addition to removal of /usr/pkg.
> Although you gave me an idea, if magic symlinks is enabled
> and /usr/pkg -> /usr/os/@osrelease/pkg and depending on the kernel used
> you'll get different pkg dir. MUAHAHAHAHA 8-).
That's possible too.
> One more thing, it's nice to be able to mix binary packages and locally
> built packages, which can save time when you only need to set specific
> options for a package that happens to have a long list of
> dependencies. Being able to set PKG_DBDIR in one place would reduce the
> incidence where binary pkgs get registered to one pkg db and locally
> built pkgs get registered to another pkg db.
This works just fine, if you don't do anything unexpected.
> --- pkgsrc/mk/pkgformat/pkg/pkgformat-vars.mk.orig 2011-12-13
> 11:35:48.000000000 -0500
> +++ pkgsrc/mk/pkgformat/pkg/pkgformat-vars.mk 2013-08-13
> 14:25:36.000000000 -0400
> @@ -15,8 +15,21 @@
I don't think that this isn't practical since _PKGDB_DIR is set correctly
when you run bootstrap script. If you don't, then you're basically on
your own. And here you add another fork+exec just to accomodate to your
rather peculiar goals.
BCE HA MOPE!
Main Index |
Thread Index |