- Status New
- Percent Complete
- Task Type Bug Report
- Category tools → prt-get
-
Assigned To
jw - Operating System CRUX
- Severity Low
- Priority Very Low
- Reported Version Development
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
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
Loading...
Available keyboard shortcuts
- Alt + ⇧ Shift + l Login Dialog / Logout
- Alt + ⇧ Shift + a Add new task
- Alt + ⇧ Shift + m My searches
- Alt + ⇧ Shift + t focus taskid search
Tasklist
- o open selected task
- j move cursor down
- k move cursor up
Task Details
- n Next task
- p Previous task
- Alt + ⇧ Shift + e ↵ Enter Edit this task
- Alt + ⇧ Shift + w watch task
- Alt + ⇧ Shift + y Close Task
Task Editing
- Alt + ⇧ Shift + s save task
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.