New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is it possible to provide binary for FreeBSD #3716

Closed
PeterDaveHello opened this Issue Nov 9, 2015 · 31 comments

Comments

Projects
None yet
9 participants
@PeterDaveHello
Member

PeterDaveHello commented Nov 9, 2015

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!

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis
Member

bnoordhuis commented Nov 9, 2015

@PeterDaveHello

This comment has been minimized.

Show comment
Hide comment
@PeterDaveHello
Member

PeterDaveHello commented Nov 9, 2015

Thanks @bnoordhuis

@PeterDaveHello

This comment has been minimized.

Show comment
Hide comment
@PeterDaveHello

PeterDaveHello Nov 9, 2015

Member

Is there a repo for the build info or build process?

Member

PeterDaveHello commented Nov 9, 2015

Is there a repo for the build info or build process?

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
Member

bnoordhuis commented Nov 9, 2015

@PeterDaveHello

This comment has been minimized.

Show comment
Hide comment
@PeterDaveHello

PeterDaveHello Nov 9, 2015

Member

Oops, seems I missed it, will take a look at it.

Member

PeterDaveHello commented Nov 9, 2015

Oops, seems I missed it, will take a look at it.

@chvostek

This comment has been minimized.

Show comment
Hide comment
@chvostek

chvostek Nov 9, 2015

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 commented Nov 9, 2015

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.

@PeterDaveHello

This comment has been minimized.

Show comment
Hide comment
@PeterDaveHello

PeterDaveHello Nov 9, 2015

Member

@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 :)

Member

PeterDaveHello commented Nov 9, 2015

@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 :)

@chvostek

This comment has been minimized.

Show comment
Hide comment
@chvostek

chvostek Nov 9, 2015

@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.

chvostek commented Nov 9, 2015

@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.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Nov 9, 2015

Member

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.

Member

mikeal commented Nov 9, 2015

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.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Nov 9, 2015

Member

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.

Member

mikeal commented Nov 9, 2015

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.

@PeterDaveHello

This comment has been minimized.

Show comment
Hide comment
@PeterDaveHello

PeterDaveHello Nov 9, 2015

Member

@chvostek

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.

Member

PeterDaveHello commented Nov 9, 2015

@chvostek

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.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Nov 9, 2015

Member

@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

Member

mikeal commented Nov 9, 2015

@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

@PeterDaveHello

This comment has been minimized.

Show comment
Hide comment
@PeterDaveHello

PeterDaveHello Nov 9, 2015

Member

@chvostek

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++"
  fi

and 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.

Member

PeterDaveHello commented Nov 9, 2015

@chvostek

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++"
  fi

and 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.

@PeterDaveHello

This comment has been minimized.

Show comment
Hide comment
@PeterDaveHello

PeterDaveHello Nov 9, 2015

Member

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.

Member

PeterDaveHello commented Nov 9, 2015

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.

@jbergstroem

This comment has been minimized.

Show comment
Hide comment
@jbergstroem

jbergstroem Nov 9, 2015

Member

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.

Member

jbergstroem commented Nov 9, 2015

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.

@mikeal

This comment has been minimized.

Show comment
Hide comment
@mikeal

mikeal Nov 9, 2015

Member

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.

Member

mikeal commented Nov 9, 2015

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.

@jbergstroem

This comment has been minimized.

Show comment
Hide comment
@jbergstroem

jbergstroem Nov 9, 2015

Member

@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

Member

jbergstroem commented Nov 9, 2015

@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

@watson

This comment has been minimized.

Show comment
Hide comment
@watson

watson Nov 10, 2015

Member

@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

Member

watson commented Nov 10, 2015

@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

@chvostek

This comment has been minimized.

Show comment
Hide comment
@chvostek

chvostek Nov 12, 2015

@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".

chvostek commented Nov 12, 2015

@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".

@chvostek

This comment has been minimized.

Show comment
Hide comment
@chvostek

chvostek Nov 12, 2015

@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.

chvostek commented Nov 12, 2015

@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.

@chvostek

This comment has been minimized.

Show comment
Hide comment
@chvostek

chvostek Nov 12, 2015

@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.

chvostek commented Nov 12, 2015

@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.

@jbergstroem

This comment has been minimized.

Show comment
Hide comment
@jbergstroem

jbergstroem Nov 12, 2015

Member

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.

Member

jbergstroem commented Nov 12, 2015

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.

@PeterDaveHello

This comment has been minimized.

Show comment
Hide comment
@PeterDaveHello

PeterDaveHello Nov 13, 2015

Member

@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?

  1. Can we provide pre-built binary package for FreeBSD just like for Linux?
  2. 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 :)

Member

PeterDaveHello commented Nov 13, 2015

@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?

  1. Can we provide pre-built binary package for FreeBSD just like for Linux?
  2. 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 :)

@chvostek

This comment has been minimized.

Show comment
Hide comment
@chvostek

chvostek Nov 20, 2015

@PeterDaveHello - I can answer those questions with some confidence, I think.

  1. 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.
  2. 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. :)

chvostek commented Nov 20, 2015

@PeterDaveHello - I can answer those questions with some confidence, I think.

  1. 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.
  2. 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. :)

@rodrigc

This comment has been minimized.

Show comment
Hide comment
@rodrigc

rodrigc Dec 22, 2015

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.

rodrigc commented Dec 22, 2015

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.

@jasnell

This comment has been minimized.

Show comment
Hide comment
@jasnell

jasnell Apr 4, 2016

Member

@nodejs/build ... further thoughts on this one?

Member

jasnell commented Apr 4, 2016

@nodejs/build ... further thoughts on this one?

@jbergstroem

This comment has been minimized.

Show comment
Hide comment
@jbergstroem

jbergstroem Apr 4, 2016

Member

@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.

Member

jbergstroem commented Apr 4, 2016

@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.

@jbergstroem jbergstroem closed this Apr 4, 2016

@targos targos referenced this issue May 4, 2017

Closed

deps: update V8 to 5.8 #12784

2 of 2 tasks complete
@rasteiner

This comment has been minimized.

Show comment
Hide comment
@rasteiner

rasteiner Dec 7, 2017

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 commented Dec 7, 2017

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.

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Dec 7, 2017

Member

@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.

Member

bnoordhuis commented Dec 7, 2017

@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.

@rasteiner

This comment has been minimized.

Show comment
Hide comment
@rasteiner

rasteiner Dec 7, 2017

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  amd64

I 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.

rasteiner commented Dec 7, 2017

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  amd64

I 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.

@bnoordhuis

This comment has been minimized.

Show comment
Hide comment
@bnoordhuis

bnoordhuis Dec 7, 2017

Member

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...

Member

bnoordhuis commented Dec 7, 2017

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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment