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: Toby Karyadi <toby.karyadi%gmail.com@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 14:57:35 -0400

 Yup, I absolutely agree with you that there should be a separation 
 between the build machinery and installation machinery and you are 
 absolutely right that pkg_install.conf should not have anything to do 
 with build mechanics. However, that separation should go both ways, i.e. 
 the build mechanics should not be clobbering the settings that is only 
 pertinent during installation. From my grepping, 
 ${PKGSRC}/mk/pkgformat/pkg/pkgformat-vars.mk assigns the default if not 
 set to PKG_DBDIR?= /var/db/pkg and this file is indirectly included by 
 mk/bsd.pkg.mk, which in turn is included by all Makefile in pkgsrc. If 
 you set that assignment to some other value, e.g. '/fu/bar/blah', and 
 there is no PKG_DBDIR in /etc/mk.conf and do 'make -V PKG_DBDIR' under 
 the top pkgsrc dir it would show '/fu/bar/blah'. This tells me that this 
 is where the build machinery decides for itself what the default for 
 PKG_DBDIR, which is really the responsibility of the pkg_* tools, which 
 depend on pkg_install.conf or values from the environment. Getting the 
 default value through 'pkg_admin config-var PKG_DBDIR', and using the 
 hardcoded default as a last resort, would solve this problem. I also 
 tested that if PKG_DBDIR is set in /etc/mk.conf, say, to 
 PKG_DBDIR=/frooble/flop/dir, then 'make -V PKG_DBDIR' would show 
 /frooble/flop/dir, as expected. The patch below might illustrate what I 
 meant.
 
 Moreover, frobbing around in mk/pkgformat/pkg would show that the build 
 machinery already depends on pkg_admin to check for dependencies, e.g. 
 in mk/pkgformat/pkg/depends.mk which eventually calls one of the *.awk 
 files to generate the dependency list using pkg_admin pmatch. This 
 indicates that the build machinery does depend on the pkg management, or 
 binary installation machinery, same thing. Additionally if you look at 
 one of the targets defined in mk/install/install.mk, 
 _pkgformat-register, it looks like  it's doing something that is most 
 probably also done by pkg_add. So that disputes the point that there is 
 a big separation between the build mechanics and installation mechanic 
 and pkg registration. But, on the other hand this tight coupling is 
 localized under the pkgformat 'interface', and that's fine, I think. My 
 point is that there is a degree of dependence of the build machinery on 
 the pkg management system and additionally tight coupling in a very 
 localized area, which is to say that the separation might not be as 
 clean as you think it should be. Since pkgsrc make already depends on 
 pkg_*, it better take pkg_* setting (i.e. settings in pkg_install.conf), 
 unless of course it is explicitly overriden in /etc/mk.conf.
 
 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.  If the /usr/pkg is deleted, the pkg db will 
 be automatically consistent with the fact that none of the pkgs is 
 installed. 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-).
 
 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.
 Cheers,
 Toby
 
 
 
 --- 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 @@
   USE_TOOLS+=    date
   .endif
 
 +PKG_ADD_CMD?=          ${PKG_TOOLS_BIN}/pkg_add
 +PKG_ADMIN_CMD?=                ${PKG_TOOLS_BIN}/pkg_admin
 +PKG_CREATE_CMD?=       ${PKG_TOOLS_BIN}/pkg_create
 +PKG_DELETE_CMD?=       ${PKG_TOOLS_BIN}/pkg_delete
 +PKG_INFO_CMD?=         ${PKG_TOOLS_BIN}/pkg_info
 +PKG_VIEW_CMD?=         ${PKG_TOOLS_BIN}/pkg_view
 +LINKFARM_CMD?=         ${PKG_TOOLS_BIN}/linkfarm
 +
   # This is the package database directory for the default view.
 -PKG_DBDIR?=            /var/db/pkg
 +.if !defined(PKG_DBDIR)
 +PKG_DBDIR!=            ${PKG_ADMIN_CMD} config-var PKG_DBDIR
 +.  if empty(PKG_DBDIR)
 +PKG_DBDIR=             /var/db/pkg
 +.  endif
 +.endif
 
   # _PKG_DBDIR is the actual packages database directory where we register
   # packages.
 @@ -27,14 +40,6 @@
   _PKG_DBDIR=            ${_CROSS_DESTDIR}${DEPOTBASE}
   .endif
 
 -PKG_ADD_CMD?=          ${PKG_TOOLS_BIN}/pkg_add
 -PKG_ADMIN_CMD?=                ${PKG_TOOLS_BIN}/pkg_admin
 -PKG_CREATE_CMD?=       ${PKG_TOOLS_BIN}/pkg_create
 -PKG_DELETE_CMD?=       ${PKG_TOOLS_BIN}/pkg_delete
 -PKG_INFO_CMD?=         ${PKG_TOOLS_BIN}/pkg_info
 -PKG_VIEW_CMD?=         ${PKG_TOOLS_BIN}/pkg_view
 -LINKFARM_CMD?=         ${PKG_TOOLS_BIN}/linkfarm
 -
   # Latest versions of tools required for correct pkgsrc operation.
   .if make(replace) && ${_USE_DESTDIR} != "no"
   PKGTOOLS_REQD=         20100914
 


Home | Main Index | Thread Index | Old Index