Can we install packages in /usr/pkg instead of /usr/local in freebsd?

F

fateh

Hi team

Can we install packages in /usr/pkg instead of /usr/local? My manager gave mk.conf file from netbsd and asking to leverage it for freebsd, I tried implementing make.conf and installed packages in /usr/local which is default location, we were able to use services but if I install in /usr/pkg and trying to start apache24 service it says below.

root@freebsd14:/var/log # service apache24 status
apache24 does not exist in /etc/rc.d or the local startup
directories (/usr/local/etc/rc.d), or is not executable

Is it recommended? If yes, does anyone aware of how to do this?
If it is not recommended please give me the reasons?

Thanks
 
/usr/local/ is definitely for local executables, libraries, etc, installed by pkg(7) or ports(7); see hier(7).

I don't see an alternative in pkg.conf(5).
 
The system-wide runtime setting is sysctl user.localbase, which is also used by rc(8) to find the default path for package/ports init scripts.

If you only install some packages/ports in a different prefix and need init scripts from them, you can override (extend) local_startup in /etc/rc.conf, e.g. local_startup="${local_startup} /usr/pkg/etc/rc.d"

fateh said:
Is it recommended? If yes, does anyone aware of how to do this?
If it is not recommended please give me the reasons?
Click to expand...
I wouldn't recommend it, simply because the default just works out of the box. But then, I didn't really understand why you think you need to do that...
 
fateh said:
Can we install packages in /usr/pkg instead of /usr/local? My manager gave mk.conf file from netbsd and asking to leverage it for freebsd
Click to expand...
If you want /usr/pkg and packages like on NetBSD, you can install pkgsrc packaging system and use it separately.

Or, easy way, adapt make.conf to FreeBSD system and use ports (set options of package during building).
 
T-Aoki said:
you would need building all ports you need locally [...] overriding LOCALBASE.
Click to expand...
Not necessarily. LOCALBASE is the prefix where a port expects other ports (its dependencies) to be installed. The port itself will be installed to PREFIX, which defaults to LOCALBASE.

So, it's perfectly possible to "single out" a port to be installed somewhere else. But having multiple prefixes will most likely lead to issues when things get more complex, e.g. something isn't found at runtime because only sysctl user.localbase is considered (see rc(8) mentioned above), or you try to build a port with dependencies installed into different prefixes (just impossible), etc ...

In the end, it makes sense to just keep the default with everything installed in /usr/local, unless you have a "very good" reason to do otherwise ... waiting for suggestions what that very good reason could be ?
 
zirias@ said:
waiting for suggestions what that very good reason could be ?
Click to expand...
The reason I started pkg_bundle on OpenBSD is so that people could install software on a shared system without needing root privileges. It also meant that multiple versions of the same software could be installed side by side.

Some of this could be avoided via chroot / jails but that is more difficult to implement securely.
 
zirias@ said:
you can override (extend) local_startup in /etc/rc.conf, e.g. local_startup="${local_startup} /usr/pkg/etc/rc.d"
Click to expand...
Shouldn't that be local_startup="/usr/pkg/etc/rc.d" ?

One more unmentioned configuration needs to be set: executables directories /usr/pkg/sbin:/usr/pkg/bin preceding :/usr/local/*: added to $PATH.
 
T-Daemon said:
Shouldn't that be local_startup="/usr/pkg/etc/rc.d" ?
Click to expand...
Not unless you want to ignore init-scripts in the default prefix. In that case, it would probably make more sense to change sysctl user.localbase, this is used for the default value of local_startup.
 
zirias@ said:
Not unless you want to ignore init-scripts in the default prefix.
Click to expand...
I asked because /etc/defaults/rc.conf has a different approach:
Code: 
23 # Set default value of _localbase if not previously set
24 : ${_localbase:="/usr/local"}

70 local_startup="${_localbase}/etc/rc.d" # startup script dirs.
It would translate to local_startup="/usr/local/etc/rc.d"

Does that mean how it is handled in /etc/defaults/rc.conf is not optimal?


zirias@ said:
it would probably make more sense to change sysctl user.localbase, this is used for the default value of local_startup.
Click to expand...
sysctl(8) user.localbase seems has no effect, whereas local_startup in /etc/rc.conf has.

(Taking here security/fakeident as example. It has almost no all-depends dependencies):
Code: 
# sysctl user.localbase
user.localbase: /usr/pkg

# ls /usr/pkg/etc/rc.d/fakeidentd
/usr/pkg/etc/rc.d/fakeidentd

# service fakeidentd start
fakeidentd does not exist in /etc/rc.d or the local startup
directories (/usr/local/etc/rc.d), or is not executable

local_startup
Code: 
# grep local_startup /etc/rc.conf
local_startup="${local_startup} /usr/pkg/etc/rc.d"

# service fakeidentd start
Starting fakeidentd.
 
T-Daemon said:
sysctl(8) user.localbase seems have no effect, whereas local_startup in /etc/rc.conf has.
Click to expand...
Probably need to reboot. It's set in /etc/rc:
Code: 
_localbase=`/sbin/sysctl -n user.localbase 2> /dev/null`
Whereas /etc/rc.conf (and /etc/defaults/rc.conf) get evaluated every time an rc(8) script calls /etc/rc.subr. So changing user.localbase isn't queried 'on-the-fly', only at boot when /etc/rc is executed.
 
T-Daemon said:
sysctl(8) user.localbase seems have no effect, whereas local_startup in /etc/rc.conf has.
Click to expand...
SirDice said:
Probably need to reboot. It's set in /etc/rc:
Click to expand...
Nope, checked it right now.

Code: 
# grep localbase /etc/sysctl.conf
user.localbase=/usr/pkg

reboot system (VM, 14.1-RELEASE-p5)
Code: 
# sysctl user.localbase
user.localbase: /usr/pkg

# service fakeidentd start
fakeidentd does not exist in /etc/rc.d or the local startup
directories (/usr/local/etc/rc.d), or is not executable
 
T-Daemon said:
One more unmentioned configuration needs to be set: executables directories /usr/pkg/sbin:/usr/pkg/bin preceding :/usr/local/*: added to $PATH.
Click to expand...
/usr/pkg/sbin:/usr/pkg/bin must precede all other $PATH executable directories, or else, /usr/sbin/pkg is called instead of /usr/pkg/sbin/pkg when executed, trying to fetch package pkg from remote repository for installation.
 
If you're setting user.localbase in /etc/sysctl.conf, does any difference happen when you set it in /boot/loader.conf[.local]?
It seems to be a tunable, too.
So if the check in /etc/rc happenes on quite early stage before reading /etc/sysctl.conf (sorry, not actually read /etc/rc script and its friends), there can be difference.
 
T-Aoki said:
So if the check in /etc/rc happenes on quite early stage before reading /etc/sysctl.conf
Click to expand...
That's indeed the case. /etc/rc.d/sysctl is typically the first rc.d(8) script, but those are still started after _localbase=`/sbin/sysctl -n user.localbase 2> /dev/null` in /etc/rc.
 
Thanks everyone for your answers. Seems like I have done few of the testings that you guys are recommending but still no luck. The packages list that he gave me is from NetBSD, so i did lot of manual work to find correct similar package for FreeBSD and updated the package list and installed almost 745 packages with the help of shell script. so /usr/pkg is netbsd default location and /usr/local is freebsd default location. so one or two packages we can alter but can't alter all of the packages, so best recommended way is to go with /usr/local. Thanks again.
 
T-Aoki said:
If you're setting user.localbase in /etc/sysctl.conf, does any difference happen when you set it in /boot/loader.conf[.local]?
Click to expand...

Good thinking, but it makes no difference:
Code: 
# grep  localbase  /boot/loader.conf  /etc/sysctl.conf
/boot/loader.conf:user.localbase="/usr/pkg"

reboot system

# sysctl user.localbase
user.localbase: /usr/pkg

# service fakeidentd start
fakeidentd does not exist in /etc/rc.d or the local startup
directories (/usr/local/etc/rc.d), or is not executable
 
Yep, that's obviously a bug. It will work just once, during initial system boot, but will fail with manual usage via service later.

T-Daemon regarding your earlier question, my scenario was to add another prefix for rc scripts, without changing localbase, and therefore just including the original local_startup.
 
You must log in or register to reply here.
Back
Top