Update Node-js V4.x auf V6.x

apollon77

~~@olifre:~~

Meiner Meinung nach sollte: `

Super Ideen. Vor allem auch anstelle dem "cd .." kram direkt den Pfad zu merken, das chmod am Anfang ist auch sinnvoll.

Wenn Du magst pass es an und liefere es als Pull-Request ein oder schreib es im Forum, dann übernehme ich es.

Ich würde Sonntag da nochmal reinschauen (bin jetzt 2 Tage unterwegs) oder Bluefox ist schneller. :-)

Ingo F

aquapro

EDIT sagt: Frage nicht mehr relevant.

Gruß

Tino

Fitti

Jaja, die immer und überall geführten Diskussionen… 8-)
~~@apollon77:~~

Ich denke ein Adapter zu haben der nur unter 6.x läuft bedeutet das Ihn aktuell fast niemand nutzen kann/nutzt, damit istdie Frage ob der ENtwickler damit zufrieden ist :) Ich glaube es ist noch zu früh. `
Das sehe ich genauso.
~~@apollon77:~~

Also danach ist node 4.x bis April 2017 noch im "kriegt regelmäßige Updates"-Modus und dann bis April 2018 noch im Maintenance (=Bugfixing) Support. `
Und selbst danach… viele nutzen überhaupt nicht die aktuellsten Patche, da auch überhaupt nicht notwendig. Wer sein System frei macht ist selber schuld. Mein ioBroker läuft stark abgeschirmt.
~~@apollon77:~~

Ich denke ab April sollten wir die 6.x als "Empfehlung" setzen und die 4.x als "geht auch noch für mind 1 Jahr) :-) `
Macht mir natürlich sorgen. Mein ioBroker will einfach nicht vernünftig auf einem Raspi, Banana oder Cubi laufen. Wahrscheinlich zu viel drauf. Vor allem Speichernutzung und CPU Takt sind Primärprobleme. Aber auch schlechte Images von Herstellern.

I. d. Tat habe ich noch nie eine solch problemlose Installation wie auf der Synolgie gehabt. Hier bin ich aber eingeschränkter in den Versionen.

Und dennoch laufen große Videokonverter, CMS-Systeme, Datenbanken usw.. Und ein ioBroker Adapter, der zumeist nur einfache Aufgaben erledigt, benötigt nun das allerneueste?

Aus wirtschaftlichen Gründen ist es auch ideal,da diese die ganze Zeit läuft.

Ich bitte es nochmal wirklich zu durchdenken, ob nun der eine neue gute Befehl, der mit 10 weiteren Codezeilen auch so erledigt werden kann, das rechtfertigt. Es steigt auch nicht jeder gleich auf Windows 10 um.

Oft ist es doch nur die Detailverliebtheit von Programmierern und nicht die technische Notwendigkeit. Das kenne ich aus vielen beruflichen Situationen genauso. Admins und Entwicklung streiten oft über die Ansichten.

Letztendlich verliert immer nur der User/Kunde.

Ich wollte einfach mal eine andere Sichtweise aufbringen.

Fitti

apollon77

~~@Fitti:~~

~~@apollon77:~~

Ich denke ab April sollten wir die 6.x als "Empfehlung" setzen und die 4.x als "geht auch noch für mind 1 Jahr) :-) `
Macht mir natürlich sorgen.

…

Ich bitte es nochmal wirklich zu durchdenken, ob nun der eine neue gute Befehl, der mit 10 weiteren Codezeilen auch so erledigt werden kann, das rechtfertigt. Es steigt auch nicht jeder gleich auf Windows 10 um.

Oft ist es doch nur die Detailverliebtheit von Programmierern und nicht die technische Notwendigkeit. Das kenne ich aus vielen beruflichen Situationen genauso. Admins und Entwicklung streiten oft über die Ansichten.

Letztendlich verliert immer nur der User/Kunde. `

Valide Sichtweise und ich kann Dir versichern das denke keiner der Entwickler absichtlich Nutzer aussperren wird - vor allem nicht für bestehende Funktionen. Auch wenn die "Empfehlung für neue Installation" (so bezeichne ich es mal) höher ist ändert sich nicht so viel.

Man muss aber auch sagen das halt node 0.x im Speichermanagement einige Probleme hatte, es mit 4.x besser ist und 6.x nochmal besser sein soll.

Als Entwickler im nodejs-Umfeld muss man aber auch die Abhängigkeiten berücksichtigen. Man baut nicht alles selbst sondern nutzt Libraries. Wenn man also Funktionen nicht selbst bauen will und eine Library findet kann es sein das diese schon eine node-Limitierung vorgibt. Ich baue gerade einen Adapter um Smartmeter per SML auszulesen und da gibt es eine Library die ich nutzen kann für das Protokoll. Diese ist aber erst ab node 4.x funktionsfähig … und schon ist das Limit da ... entweder ich baue das jetzt selbst nochmal nach oder ich überzeuge den Library-Entwickler das umzubauen oder ich akzeptiere es ... Schwierig ... :-)

Naja, wir schauen einfach mal wie es weitergeht und nehmen jedes Feedback von "falschen" Abhängigkeiten und versuchen Sie weg zu machen ,,,

apollon77

~~@fsjoke:~~

Ich habe das original-script für Linux etwas abgeändert: `

Ich habe auch mal ein bissl gespielt und komme mit den Ideen aus dem Thread hier zu folgendem:

iobroker stop
BASE=$(pwd)

if [ -d ./node_modules ]
then
    ls -1 ./node_modules | grep iobroker. > reinstall.list.txt
    chmod 777 * -R
    cd node_modules
    rm -R *
    pwd

    while read IN
    do
        npm install $IN --production
        if [ $? -eq 0 ]
        then
            if [ -d ./node_modules/$IN ]
            then
                cd node_modules/$IN/
                npm install --production
                cd "$PWD"
            fi
            echo "DONE $IN"

        else
            echo "FAIL $IN"
        fi

    done < "$BASE/reinstall.list.txt"
    chmod 777 * -R
    rm "$BASE/reinstall.list.txt"
    iobroker upload all
fi

bisher trocken auf meinem Rechner mit nem projekt getestet … muss ich heute Abend mal auf meinen iobroker-Testhost loslassen.

Andere Tester wilkommen :-)

Ingo F

frankjoke

Nur 'ne Frage Ingo,

warum rufst du install 2x auf?

! ````
npm install $IN --production
if [ $? -eq 0 ]
then
if [ -d ./node_modules/$IN ]
then
cd node_modules/$IN/
npm install --production


Das 1\. install installiert schon alles und man muss nicht nochmal ins Verzeichnis des Modules reingehen um es nochmal zu installieren!

Der effekt (bei älteren npm's) ist nur dass module 2x heruntergeladen werden, einmal in ioboker/node_modules und einmal in iobroker/node_modules/iobroker.adapter/node_modules

Der Sinn von Node/npm ist alle Modulversionen in einem Projekt nur einmal lokal zu speichern.

Egal, ich weiß nicht wann damit angefangen wurde, aber es war wahrscheinlich als jemand Probleme hatte unterschiedliche Versionen auf unterschiedliche Weise zu installieren (einmnal im iobroker Hauptverzeichnis und einmal im Adapter) was dann dazu führt dass die falschen Module geladen werden!

Deshalb verwende ich falls ich in einem anderen Verzeichnis als /opt/iobroker installiere immer  ` > –prefix "/opt/iobroker" `  um nicht ein neues node_modules anzufangen.

apollon77

Diese Frage kann wohl nur Bluefox beantworten. Ich hab an der Stelle das gleiche gemacht wie das Skript davor. Ich habe es nur etwas "Fehlersicherer" gemacht … Die Frage ist aber komplett gerechtfertigt. Ich sehe es auch eher unnötig das doppelt zu machen.

@Bluefox: Any comment to this?

Bluefox

~~@apollon77:~~

Diese Frage kann wohl nur Bluefox beantworten. Ich hab an der Stelle das gleiche gemacht wie das Skript davor. Ich habe es nur etwas "Fehlersicherer" gemacht … Die Frage ist aber komplett gerechtfertigt. Ich sehe es auch eher unnötig das doppelt zu machen.

@Bluefox: Any comment to this? `
Mit npm 3,4 ist es nicht mehr nötig, aber mit npm 1 es war ein Hacken da, ich kann aber mich nicht mehr daran erinnern :)

apollon77

bei node 0.10, 0.12 und 4.x ist ein npm 2.x "dabei". Das 3er npm erst ab node 6.x

Da nopm 1 damit nirgends mehr relevant ist das doppelte rauswerfen?

@Bluefox: habs mal geändert. Siehe js-controller Pull Request

greyhound

Habe wegen diverser Probleme meine node-Version von 7.4 (siehe http://forum.iobroker.net/viewtopic.php?f=8&t=4953auf 6.9.5 zurückgestellt und dann das reinstall.sh durchlaufen lassen.

Dabei laufe ich bei mehreren Adaptern/Modulen auf folgenden Fehler:

   SUCCES iobroker.owntracks
iobroker.core@0.1.0 /opt/iobroker
└── iobroker.ping@1.2.0

   SUCCES iobroker.ping

> usb@1.2.0 install /opt/iobroker/node_modules/usb
> node-pre-gyp install --fallback-to-build

node-pre-gyp ERR! Tried to download: https://github.com/tessel/node-usb/releases/download/1.2.0/usb_bindings-v1.2.0-node-v48-linux-arm.tar.gz
node-pre-gyp ERR! Pre-built binaries not found for usb@1.2.0 and node@6.9.5 (node-v48 ABI) (falling back to source compile with node-gyp)
make: Entering directory '/opt/iobroker/node_modules/usb/build'
. . .

Aber auch ein build aus den Sourcen schlägt fehl.

Ursache ist, dass es in dem Repo kein Paket für node v6.9 gibt?

Ist euch das Problem bekannt und habt ihr einen Workaround dafür?

Anderseits frage ich mich, warum so viele Adapter eine Abhängigkeit zu USB haben. Z. B. bekomme ich selbigen Fehler auch beim heutigen Update von icons-open-icon-library-png

npm install https://github.com/ioBroker/ioBroker.icons-open-icon-library-png/tarball/master --production --prefix "/opt/iobroker" (System call)
node-pre-gyp
 ERR! Tried to download: https://github.com/tessel/node-usb/releases/download/1.2.0/usb_bindings-v1.2.0-node-v48-linux-arm.tar.gz node-pre-gyp ERR! Pre-built binaries not found for usb@1.2.0 and node@6.9.5 (node-v48 ABI) (falling back to source compile with node-gyp) 

../libusb/libusb/os/linux_udev.c:40:21: fatal error: libudev.h: No such file or directory #include <libudev.h>^
compilation terminated.
...</libudev.h>

frankjoke

greyhound,

Ich würde 7 nur für Tests einsetzten aber hatte mit 4 und 6 auch schon ähnliche Probleme.

Die Probleme verschwanden bei mir sobald ich Adapter nur von den npm-repos (also npm install iobroker.adapter und nicht npm install von_git…..) gemacht habe.

Noch schlechter war's wenn ich git clones gemacht habe um die Adapter lokal zu bearbeiten/debuggen/und wieder auf upzudaten, dann konnte ich nichts mehr installieren bis ich das Verzeichnis in node_modules gelöscht hab.

Habe nach downgrade von 6 auf 4 auch noch ein Problem gehabt dass ich alle npm caches löschen musste und auch ioBroker+Adapter neu installieren musste (komplettes node_modules löschen).

apollon77

~~@greyhound:~~

../libusb/libusb/os/linux_udev.c:40:21: fatal error: libudev.h: No such file or directory #include <libudev.h>^

compilation terminated.

…</libudev.h> `

Das liegt an sich nicht an node 6.x/7.x … installiere mal

apt-get install libusb-1.0-0.dev libudev-dev

Dann sollte das Problem weg sein!

greyhound

Danke für den Hinweis, das hatte ich schon probiert, es kommt aber immer folgender Fehler:

The following packages have unmet dependencies:
 libudev-dev : Depends: libudev1 (= 215-17+deb8u6) but 230-7~bpo8+2 is to be installed
E: Unable to correct problems, you have held broken packages.

Aber

apt-get remove libudev1

und ein anschließendes

apt-get install libudev-dev

Haben das Problem zumindest gelöst.

greyhound

~~@greyhound:~~

Aber
apt-get remove libudev1
und ein anschließendes
apt-get install libudev-dev
Haben das Problem zumindest gelöst. `
aber leider nur bis zum nächsten reboot. Musste dann ziemlich umständlich wieder die alten Packages auf das Image kopieren und neu installieren.

Gruß

GH

apollon77

hä ?!

greyhound

ach ja,

vergaß wohl das wichtigste, mit dem

apt-get remove libudev1
Remove: libudev1:armhf (230-7~bpo8+2), libdevmapper1.02.1:armhf (1.02.90-2.2+deb8u1), initramfs-tools:armhf (0.120+deb8u2), systemd-sysv:armhf (230-7~bpo8+2), libcryptsetup4:armhf (1.6.6-5), systemd:armhf (230-7~bpo8+2), dmsetup:armhf (1.02.90-2.2+deb8u1), libbluetooth3:armhf (5.23-2+b1), libbluetooth-dev:armhf (5.23-2+b1), udev:armhf (230-7~bpo8+2), bluez:armhf (5.23-2+b1), libusb-1.0-0:armhf (1.0.19-1), usbutils:armhf (007-2), bluetooth:armhf (5.23-2)

wird leider etwas mehr entfernt als ich dachte. Und mit

apt-get install libudev-dev
Install: libudev1:armhf (215-17+deb8u6, automatic), libdevmapper1.02.1:armhf (1.02.90-2.2+deb8u1, automatic), libcryptsetup4:armhf (1.6.6-5, automatic), dmsetup:armhf (1.02.90-2.2+deb8u1, automatic)

weniger wieder installiert.

Damit fehlte dann so einiges für USB, Bluetooth und auch der systemd. Ohne den systemd startet bei meinem odroid XU4 das Netzwerk nicht mehr, kein eth0.

AlCalzone

~~@Blackmike:~~

apt-get --purge remove node
apt-get --purge remove nodejs
apt-get autoremove
reboot

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -
sudo apt-get install -y build-essential python nodejs
reboot
```` `

Genauso habe ich am Wochenende Versucht, meinen Pi von NodeJS 0.10.22 auf 6.X zu aktualisieren. apt-get war aber der Meinung, dass ich doch lieber 0.10.29 will, obwohl ich explizit eine andere Version angegeben habe.

Gelöst habe ich es dann mit dem "n"-Paket:

sudo npm install -g n
sudo n lts

War wesentlich unkomplizierter und hat auf Anhieb funktioniert.

Homoran

~~@AlCalzone:~~

apt-get war aber der Meinung, dass ich doch lieber 0.10.29 will `
ist das ein Pi1?

Gruß

Rainer

AlCalzone

Nein, ein Pi2, den ich nach Anleitung aus dem Forum zuvor von Wheezy auf Jessie geupdated habe.

frankjoke

Ah ja, original Jessie gibt noch immer 0.1x bei und du hast sicher nicht

curl -sL https://deb.nodesource.com/setup_6.x | sudo -E bash -

oder

curl -sL https://deb.nodesource.com/setup_4.x | sudo -E bash -

gemacht um die nodejs-source für apt-get auf 6.x oder 4.x umzuistellen.

ioBroker basis läuft auf allen aber es gibt einige Adapter die nur ab 4.x laufen.

Community Forum

NEWS

Update Node-js V4.x auf V6.x

Support us

798

32.4k

81.4k

1.3m