Is it possible to provide binary for FreeBSD
PeterDaveHello opened this issue · comments
Hi there, I just want to know is it possible to provide the dist binary for FreeBSD just like linux (e.g. https://nodejs.org/dist/v5.0.0/node-v5.0.0-linux-x64.tar.xz), if the work will need contribution, how can I contribute to it? Thanks!
/cc @nodejs/build
Thanks @bnoordhuis
Is there a repo for the build info or build process?
Yes, it's https://github.com/nodejs/build
Oops, seems I missed it, will take a look at it.
The binary you require depends on the version of FreeBSD you're running, and whether you're running in 32-bit or 64-bit. The FreeBSD project makes packages available already for all the supported options, which you can install using the pkg command.
Alternately, visit http://pkg.freebsd.org/, select your ABI, go ito "latest" and "All", then find your package. For example, for FreeBSD 10, 64-bit, you could:
$ sudo pkg add http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/node-4.2.1.txz
Note that you don't need to provide a full versioned URL like this. The quick way to install a bianry package of nodejs in FreeBSD would be:
# pkg install nodejs
It's generally recommended to use binary packages provided by the FreeBSD packaging ecosystem, so that it can be registered in your machine's local package database and so that dependencies are tracked properly.
@chvostek thanks for reply, but as you can see, the package(also the ports) on FreeBSD is in fact out-dated v4.2.1, Debian/Ubuntu/CentOS/Fedora ... such linux distros also have their eco-system, but it'll be very great to have the official and fresh releases!
One another reason I want to have the pre-built binary is for the nvm support :)
@PeterDaveHello ... Any packaging system is going to lag behind official product releases a little. The FreeBSD port for node 4.2.1 was updated 4 days after that version was released. I would recommend against increasing your technical debt by making future upgrades more difficult.
You can always check with the maintainer of the port, listed at http://www.freshports.org/www/node, and ask when they're planning to update the port to the most recent nodejs release. In my experience, most port maintainers are very responsive to polite requests like this.
As for nvm... Well, bear in mind that nvm and node are separate things, and the availability of a node binary package does not mean you have nvm available. nvm (1) has not been ported to FreeBSD and (2) won't run in FreeBSD as-is. No doubt your contributions to that project would be welcome, but unless someone has a FreeBSD-compatible fork that I haven't seen, I suspect you won't be running nvm in FreeBSD any time soon.
Well, bear in mind that nvm and node are separate things, and the availability of a node binary package does not mean you have nvm available
I believe that nvm actually pulls from our json definition for releases so it should automatically have the latest binaries.
Any packaging system is going to lag behind official product releases
So, I'd like to push back a little on this. We hear this a lot, especially from debian maintainers, that there's some nebulous "process" by which package managers will take some variable amount of time to update. In some cases they even credit this process with encouraging stability or security.
While in our current situation package managers lag behind, that isn't how it should be, and it means those users are inherently less stable and less secure because of it. With v4 in our LTS cycle we have a high bar for disruptive changes. The vast majority of releases in LTS will be bug fixes and security improvements.
Make no mistake, the experts on Node.js stability and security are in the LTS working group and not whoever happens to manage the Node.js package for an operating systems package manager.
In the case of Node.js the process that disconnects the LTS/Build WGs from updates to our users does nothing but decrease stability and security for those users. My hats off to the people who do the work of maintaining those packages, especially those that get in timely updates, but if we were able to bring them in to the project and make updating those resources part of the regular release process as we do with docker already we would have more stability and security in the hands of our users.
I understand that this is not how things are typically done in OS package managers but at the moment the users who enjoy the greatest level of stability and security are those who update from us directly or from docker and processes that lag behind them do a disservice to our users who depend on those systems for updates.
Any packaging system is going to lag behind official product releases a little.
Yes I know that, and that's the reason why I hope there could be a binary package release as for linux. Hope my pool English skill didn't ambious the focus.
@PeterDaveHello that's not a bad idea. We have some FreeBSD resources already that we use for running tests so perhaps this is just a matter of adding them to our build step. You should log an issue in the Build Working Group about adding pre-built packages for FreeBSD :) https://github.com/nodejs/build
As for nvm... Well, bear in mind that nvm and node are separate things, and the availability of a node binary package does not mean you have nvm available. nvm (1) has not been ported to FreeBSD and (2) won't run in FreeBSD as-is. No doubt your contributions to that project would be welcome, but unless someone has a FreeBSD-compatible fork that I haven't seen, I suspect you won't be running nvm in FreeBSD any time soon.
In fact, nvm pulls the binary packages from node https://nodejs.org/dist/ since nodejs v4.0.0, and nvm also looks like it supports FreeBSD. (I didn't try it by myself yet because build from source is very slow)
https://github.com/creationix/nvm/blob/master/nvm.sh#L936
nvm_get_os() {
local NVM_UNAME
NVM_UNAME="$(uname -a)"
local NVM_OS
case "$NVM_UNAME" in
Linux\ *) NVM_OS=linux ;;
Darwin\ *) NVM_OS=darwin ;;
SunOS\ *) NVM_OS=sunos ;;
FreeBSD\ *) NVM_OS=freebsd ;;
esac
echo "$NVM_OS"
}https://github.com/creationix/nvm/blob/master/nvm.sh#L1230-L1233
if [ "_$NVM_OS" = "_freebsd" ]; then
make='gmake'
MAKE_CXX="CXX=c++"
fiand sorry that I may not reply a comment at once, due to English is not my mother language, I'll need to check the dictionary and I can not read so fast.
I would recommend against increasing your technical debt by making future upgrades more difficult.
Not really understand what do you mean here, no offence, if there is a easier way to understand the meaning of the sentence, I hope somebody can tell me, if you have time, thanks.
I think the FreeBSD people are doing a great job of maintaining releases through pkg. Hopefully, we can improve it even further forward. The burden for us packaging freebsd is low once we have release bot as part of our (the build group) cluster, but I'd actually prefer FreeBSD maintainers doing it.
but I'd actually prefer FreeBSD maintainers doing it
My preference is that the maintainers of that package are integrated into the Node.js project and, hopefully, we can automate the entire process getting them up to date as we do with docker. Agreed that they are doing a good job, much better than some other operating systems I can think of, but that doesn't mean they can't be part of the project.
@mikeal I've had a todo (for a good while) about improving nodejs third party packaging laying around that elaborates on this. Just created an issue about it here: nodejs/build#245
@PeterDaveHello I think he means that installing node from other sources than your standard package manager would make it more difficult to upgrade in the future. I'm not sure that is really called technical debt though or that I agree with it
@watson and @PeterDaveHello - yes, technical debt is incurred when for the sake of short term convenience, you make choices that will require more work in the future to back out of or fix. On the software development side, think of all the PHP developers who wrote mysql support directly into their applications rather than using a database abstraction layer. Adding postgresql support after the fact becomes almost impossible. On the system administration side, installing software from source is a classic example. Developers don't see the problem with using the latest and greatest. Sysadmins, on the other hand, would usually rather have known bugs or limitations on their systems than untracked software that was installed outside the view of the package management system. Having things tracked properly provides huge benefits. (They're self evident to me, but I'm a sysadmin; let me know if you want a list.)
Aside from that, as a sysadmin responsible for servers that run mission critical nodejs software, I would never upgrade to a version of node that hadn't gone through the quality control measures that FreeBSD ports go through. As much as I would like to have faith in the project owners for each of the applications that I rely on for my paycheque (apache, php, etc), I trust the process that the FreeBSD ports system provides even more, and choose a slower release path to avoid having to rely on "faith".
@mikeal :
My preference is that the maintainers of that package are integrated into the Node.js project and, hopefully, we can automate the entire process getting them up to date as we do with docker.
I love this idea. Mechanisms for port update automation have been discussed many times over the years, but there have so rarely been project leaders willing to spend any effort at all to understand the FreeBSD ports system and how to make their software work better in FreeBSD.
Impressively, the www/node FreeBSD port requires no patches to build or install, and it has almost no dependencies. This cleanliness makes it a prime candidate for easy automation.
I would be delighted to participate in nodejs/build#245 with feedback/concerns/suggestions related to FreeBSD.
@mikeal :
You should log an issue in the Build Working Group about adding pre-built packages for FreeBSD
I'll just point out that all pre-built packages that are made available through FreeBSD's package management system are derived from the FreeBSD ports system. While I applaud the enthusiasm, the reality in FreeBSD is that folks running the FreeBSD package build cluster are exceedingly, supernaturally careful about what gets introduced to the binary package sets. Our best effort will be to streamline the port update process so that updated packages can be built from a revised port.
As a member of the build group I regularly visit packagers repos to see what patches they are floating to us or v8 and try to backport whay I can. Getting notified ahead by having open channels with packagers would obviously improve this.
@chvostek @watson sorry for the late reply, thanks for the explanation, I got your concern, and I totally agree. I think there are still some famous managers like nvm, and they have different purpose(not like the system's package manager, for example, nvm wanna provide the easiest way to install multiple nodejs and npm with different versions and the users can easily switch between them), and they'll try to have their own management to prevent the "technical debt issue". I still think there is not only one issue, maybe two?
- Can we provide pre-built binary package for FreeBSD just like for Linux?
- How to make good relationship with operating systems' packager and help them or work together to deliver the new versions in shortest time(also backport the patches).
Anyway, I appreciate all your comments and thoughts, really :)
@PeterDaveHello - I can answer those questions with some confidence, I think.
- You can build a FreeBSD package based on a custom port that you maintain, and you can distribute that package as you see fit. Your package will not be included in any official FreeBSD package repository, and the FreeBSD community will continue to recommend against using it, in favour of packages that are built using the official package build cluster.
- This is being discussed at the issue linked above.
I would suggest that the node project not create its own FreeBSD binaries, in the interest of #2. A great way to maintain a good relationship with package managers is to avoid appearing to try to subvert their established processes. :)
Right now FreeBSD has these packages:
pkg search -o node
pkg search -o npm
www/node V8 JavaScript for client and server (5.x)
www/node-devel V8 JavaScript for client and server
www/node010 V8 JavaScript for client and server
www/node012 V8 JavaScript for client and server
www/node4 V8 JavaScript for client and server (4.x LTS)
www/npm Node package manager
www/npm012 Node package manager
You can install one these packages by doing something like:
pkg install www/node
pkg install www/node4
I think the FreeBSD ports people are doing a fairly good job at maintaining these packages
and keeping them up to date. They can always use help in terms of reminders and patches
to update things.
Whether the node project wants to provide FreeBSD binaries is another question.
Based on what I see the FreeBSD ports people doing, I don't think it is necessary.
@nodejs/build ... further thoughts on this one?
@jasnell not really. I think upstream [FreeBSD] is doing a good enough job and I don't see why we need to replace that.
To install node on FreeBSD: pkg install node.
Closing this for now.
What about people on freebsd that don't have access to pkg or root rights? Like many shared hostings?
Having a working node binary would allow people to use stuff like ReactDOMServer or PDFKit or many many many other things on npm. Maybe it's just me, but to me this seems important.
@rasteiner Can you point to freebsd hosting providers that won't let you install from ports but do let you run arbitrary binaries? It seems an unlikely combination.
You could compile from source in that case. Worst case you build locally and copy over the binary.
I'll try to compile it in a VM then... :) The hosting is one of the bigger ones here in Switzerland: https://www.hostpoint.ch/en/
Not sure about "arbitrary" binaries, but I had no problems executing golang binaries... So I think running node should be possible, except if there are some dependencies that aren't available of course. Obviously I can't open any ports or stuff like that, but that's not what I intend to do.
Here's what the shell has to say:
[myuser@xxxxxx:~] $ pkg
bash: pkg: command not found
[myuser@xxxxxx:~] 127 $ uname -a
FreeBSD xxxxxxxx.hostpoint.ch 10.3-RELEASE-p24 FreeBSD 10.3-RELEASE-p24 #14 r326012M:
Mon Nov 20 12:42:55 UTC 2017 root@xxxxxxxxxxxx.ch:/usr/obj/usr/src/sys/HOSTPOINT amd64I think pkg is disabled because you don't have any root access (afaik pkg would install node at system level), but within your home directory you can pretty much do whatever you want.
I don't know if it's officially supported but I've built ports in the past from (and installed to) my home directory. I didn't use pkg, just the ports tree as a tarball or from svn.
(And if /usr/ports/www/node already exists, you can do great things with make PREFIX=... WRKDIRPREFIX=... install.)
@jbergstroem What do you think? I'm not opposed to putting out freebsd binaries but I also don't disagree with your line of reasoning. Also, I don't usually use double negatives but when I do...
I know this is an old issue, but would like to re-open this with three examples where having an official build of Node for FreeBSD would be helpful:
- Some operating systems based on FreeBSD don’t have pkg installed, as they discourage using it and messing with the OS. One example is FreeNAS, where having Node would be helpful at times.
- An official build of Node would make it possible to use NVM, which is a great tool for development and testing (and some use it for production too)
- Tools like pkg support FreeBSD but require a full recompilation of Node, which means that cross-compiling isn’t possible, and it takes forever.
For anyone coming across this issue: FreeBSD support was demoted to experimental status starting with Node.js v12.x due to a lack of volunteers. For official binaries to become a reality, that problem will have to be solved first.
Does someone know how to retrieve node8 on FreebSD12.1 (deprecated and thus has been removed from the ports tree hence no binary package)? I guess I need that version to get rocket.chat running..... Thanks.