Bug 220114

Summary: ports-mgmt/pkg unable to open database file when run from a non-existent dir
Product: Ports & Packages Reporter: Zsolt Udvari <uzsolt>
Component: Individual Port(s)Assignee: freebsd-pkg (Nobody) <pkg>
Status: Closed FIXED    
Severity: Affects Many People CC: cem, chris, freebsd, herbert, nomoo, ports.maintainer, swills, w.schwarzenfeld
Priority: ---    
Version: Latest   
Hardware: Any   
OS: Any   

Description Zsolt Udvari freebsd_committer freebsd_triage 2017-06-18 16:43:45 UTC 
$ mkdir ~/pkg_tmp
$ cd ~/pkg_tmp
$ rmdir ~/pkg_tmp
$ pwd
pwd: .: No such file or directory
$ pkg info
pkg: sqlite error while executing sqlite open in file pkgdb.c:1126: unable to open database file
$ pkg -v
1.10.1

I saw this message when I 'cd' into a directory which is owned by package "foo" (I don't remember which package but I think it's irrelevant) and some minutes later I wanted to remove "foo".
I think the error message is deceptive (I could handle the package database with sqlite and didn't understand why pkg can't access it).
Comment 1 Herbert J. Skuhra 2017-08-02 06:35:11 UTC 
I often see this error updating ports with portmaster:

# pwd
/root
# portmaster security/ca_root_nss
[...]
pkg: sqlite error while executing sqlite open in file pkgdb.c:1126: unable to open database file

If I remove pkg-message from SUB_FILES (security/ca_root_nss/Makefile) the error is gone. After more testing I think the error does not appear on 12.0-CURRENT (pkg) and 11-RELEASE/STABLE (pkg-devel).
Comment 2 Michael Büker 2017-08-17 08:01:21 UTC 
I see this error message when running "portmaster -a" on 11.1-RELEASE, right at the end of the process.
Comment 3 Steve Wills freebsd_committer freebsd_triage 2017-08-17 14:21:03 UTC 
I can confirm I've experienced this error too and agree the error message is misleading at best. The error seems unnecessary.
Comment 4 ports.maintainer 2017-08-17 22:28:19 UTC 
See this github issue: https://github.com/freebsd/pkg/issues/1552
Comment 5 Walter Schwarzenfeld freebsd_triage 2019-08-15 04:45:35 UTC 
See link in comment4. Is fixed.