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 <>
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 <> 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 
 >  installed.
 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/      2011-12-13 
 >  11:35:48.000000000 -0500
 >  +++ pkgsrc/mk/pkgformat/pkg/   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.

Home | Main Index | Thread Index | Old Index