• Status New
  • Percent Complete
  • Task Type Bug Report
  • Category tools → prt-get
  • Assigned To
  • Operating System CRUX
  • Severity Low
  • Priority Very Low
  • Reported Version Development
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: CRUX
Opened by jw - 24.05.2010

FS#595 - getPkgmkSetting() could do with a cache

getPkgmkSetting() could do with a cache, since usually within install transactions these values don't change.

Look into providing an elegant solution avoiding losing all the const/static-ness

commit b5aa185537 on the mixed-upinst branch of my forked repo https://git.sdf.org/jmq/prt-get is one attempt to implement such a cache. The idea is to make one pass through pkgmk.conf (during the initialization of m_config), and only proceed to parse /usr/bin/pkgmk if either variable (PKGMK_PACKAGE_DIR or PKGMK_COMPRESSION_MODE) is still unset. Whatever string is obtained for PKGMK_PACKAGE_DIR by these disk reads must still be shell-expanded at the time of running pkgadd, in case it contains environment variables like $PWD. Shell expansion of PKGMK_COMPRESSION_MODE could have been done similarly, but if anyone is writing PKGMK_COMPRESSION_MODE="$(echo eHoK | base64 -d)" in their /etc/pkgmk.conf, they deserve to see some breakage for not keeping it simple.

The analogous subroutine in my Perl-based rewrite https://git.sdf.org/jmq/Documentation/src/branch/master/scripts/prt-auf tries to respect not just the environment variables known at the beginning of the install transaction, but also Pkgfile variables like $name and $version, in case PKGMK_PACKAGE_DIR is defined in terms of them. But neither my Perl-based rewrite nor the forked prt-get will correctly handle pkgmk.conf tricks like PKGMK_PACKAGE_DIR=/usr/pkgmk/packages/${name:0:1}; if you want to accommodate every such bashism, you have to spawn an actual bash shell in the port directory.

I can't say much for the elegance of the C++ refactoring involved in this latest commit, nor on the side effects related to const/static-ness. But at least in preliminary testing, my fork still compiles cleanly, and behaves as expected during install/update transactions.


Available keyboard shortcuts


Task Details

Task Editing