pkg/51733: sysutils/xentools42 xl(8) does not honour PKG_SYSCONFBASE

[Hauke Fath <hf%spg.tu-darmstadt.de@localhost>]

>Number:         51733
>Category:       pkg
>Synopsis:       xentools42 xl(8) does not honour PKG_SYSCONFBASE
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Dec 21 12:20:00 +0000 2016
>Originator:     Hauke Fath
>Release:        NetBSD 7.0_STABLE
>Organization:
Technische Universitaet Darmstadt
>Environment:
	
	
System: NetBSD Eisenhut 7.0_STABLE NetBSD 7.0_STABLE (FEUERKOGEL_DOM0-$Revision$) #0: Wed May 18 13:31:12 CEST 2016 hf@Hochstuhl:/var/obj/netbsd-builds/7/amd64/sys/arch/amd64/compile/FEUERKOGEL_DOM0 amd64
Architecture: x86_64
Machine: amd64
>Description:

	What looked like a routine security patch update of the local
	dom0 xentools sped up my pulse when I saw that the domus
	failed to start.

	It turned out that in spite of

% fgrep SYSCONFBASE /etc/mk.conf
PKG_SYSCONFBASE =       /etc/pkg
%

	the newly-built sysutils/xentools42-4.2.5nb20 xl(8) expects
	its configuration under

# xl list
Failed to read config file: /usr/pkg/etc/xen/xl.conf: No such file or directory
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0   512     1     r-----     135.2
[...]
# strings /usr/pkg/sbin/xl | fgrep /usr/pkg/etc
/usr/pkg/etc/xen/xl.conf
#

	A quick symlink saved the day, but still.

	It has been a while since I updated packages on the xen
	machines in question (half a a year easily), so I cannot
	readily pinpoint the responsible change. "It used to work
	before the update."
 
	
>How-To-Repeat:

	Update xentools42 on a machine with non-default
	PKG_SYSCONFBASE. Reboot, watch the breakage.

	
>Fix:

	Use a fine comb, and patience, I guess?

	

>Unformatted: