Linux ’emulation’ packages are present in pkgsrc, same as they are in ports, but the use is slightly different. Joerg Sonnenberger detailed some of the differences in a recent post.
Updated: And check this post too.
5 Replies to “Linux emulation and pkgsrc”
Comments are closed.
“Yes, and that won’t change either. Keep in mind that e.g. NetBSD uses
/emul which would be linked to /usr/pkg/emul, see below.”
Not like the fix is difficult or anything, but IMO, it would make much more sense to just change the way the Linux compatability in DragonFly works so that it works seamlessly with pkgsrc, seeing as how pkgsrc is the default package management system now.
Seriously, why add that extra (tho trivial) series of steps to make Linux compatability work, just because historically FreeBSD did it that way?
What do you want to change? The hard-coded default to /usr/pkg/emul? What makes you believe that is the location choosen in a particular installation? /emul or /compat doesn’t make much of a difference, it’s a change without much merit.
This one hop is needed on NetBSD as well and it is not the only step needed to fully activate Linux emulation support.
It should also be kept in mind that /compat/linux doesn’t necessarily have any relation to ports or pkgsrc. On my server it is just an image of a SuSE base system with some additional rpms and Tivoli, since that is what I need Linux for. It’s a static image, no package management involved. I don’t want to pollute /usr/pkg with that.
“What do you want to change? The hard-coded default to /usr/pkg/emul?”
That was what I had in mind, yes.
“What makes you believe that is the location choosen in a particular installation?
As it seems to be the default in pkgsrc I figure it’s not a bad thing to have the Linux compat env in DragonFly look for stuff there. If other people choose to deviate from that, then leave those few extra steps to them, and not force people who choose to stick with defaults to spend the half minute it takes to make it work.
“This one hop is needed on NetBSD as well and it is not the only step needed to fully activate Linux emulation support.”
True, it is minimal, but there are a few of these minor tweaks for various things in both systems that taken together become a chore. It just seems to make more sense in my mind to remove the need to perform these minor tweaks in order to make things work “out of the box.”
“It should also be kept in mind that /compat/linux doesn’t necessarily have any relation to ports or pkgsrc. On my server it is just an image of a SuSE base system with some additional rpms and Tivoli, since that is what I need Linux for. It’s a static image, no package management involved. I don’t want to pollute /usr/pkg with that.”
That was a good example, and I thank you for that. In that case I would have to ask, are cases such as yours more common than people just using linux packages from pkgsrc (or ports in FreeBSD etc.)? If so, then yes, I can see my desire in this case to be overshadowed by the needs of other users, but if not…
Like I have written, keep in mind that a number of steps are needed anyway, whatever the builtin kernel path is. A lot of Linux programs will (silently) break without linprocfs, linux.ko is still needed to be loaded etc.
That aside, there’s also a security reason to not use /usr/pkg/emul by default: it reduces the change of unavoided impact just because e.g. jdk 1.4 was attempted to be built.
Even ignoring that, the documentation (or omissions thereof) is of course disappointing and needs to be fixed.
Thank you again for explaining your reasoning. Some of the points you brought up I hadn’t considdered.