ev3dev-lang-java/installer

Installer vs APT

JakubVanek opened this issue · 9 comments

JakubVanek commented

Hmmm, installer might be replaced by a series of deb packages. That would provide automatic updates and it would be more robust.

jabrena commented

The question with the debian packages is the time to build de tree of dependencies.
This is the reason that for EV3, I prefer to link to a concrete Debian package but we could try.

Example pointing to a concrete debian package:
https://github.com/ev3dev-lang-java/installer/blob/master/modules/battery-monitor.sh

If you like, we could create that document and do some Benhmark tests to compare restults.

JakubVanek commented

Why do you prefer downloading concrete debs?

apt-get is slower because it has to load the package database, that's for sure. But it can keep with updates and it can resolve dependencies. It would also integrate well with the rest of the system. Brickman for example is also a debian package and you don't have to install it separately.

The dependency tree is effectively there even now, it's just not enforced.

jabrena commented

The main reason is the speed. Using concrete Debian packages is faster but the solution is not scalable in the time. We will change. Besides the most important dependency is the JVM and the new download process is faster.

I will upgrade the modules where exist a concrete version. :)

JakubVanek commented

Hmm, there is an option where plain debian packages would be useful: complete self-extracting package for offline use.

Then it couldn't use APT. But it would require OpenJDK, AFAIK only then could we redistribute Java.

jabrena commented

It is not a bad idea, we should have a small solution meanwhile we don´t have many active developers.
Remember that you are defining goals in this issue:
ev3dev-lang-java/ev3dev-lang-java#413

It is a good idea, but it require more processes. I recognize that it is more elegant but it requires more time. With current process at the moment is enough:

  • JDK Build
  • Github publication
  • Installer Upgrade

If we add Debian in the cycle:

  • JDK Build
  • Debian publication
  • Installer Upgrade

When we have more active developers, we could activate this idea. If you like create a Debian packaging issue in the main backlog to consider in some moment:
https://github.com/ev3dev-lang-java/ev3dev-lang-java

I will upgrade installer for this case: native-libraries.sh

if [ "$PLATFORM" == "$UNKNOWN" ]; then
    echo "This platform: $PLATFORM is not suitable for Battery Monitor."
    echo
else
    apt-get update
    isInstalled libopencv2.4-java
    if [ "$INSTALLED" == "$INSTALLED_NO" ]; then
        apt-get install libopencv2.4-java
    fi
    isInstalled librxtx-java
    if [ "$INSTALLED" == "$INSTALLED_NO" ]; then

        if [ "$PLATFORM" == "$EV3" ]; then
            wget http://ftp.us.debian.org/debian/pool/main/r/rxtx/librxtx-java_2.2pre2-13_armel.deb
            dpkg -i librxtx-java_2.2pre2-13_armel.deb
        else
            apt-get install librxtx-java            
        fi
        
    fi
fi
jabrena commented

Fixed

JakubVanek commented

Hmmmm, apt-get update over WiFi really takes a long time. With USB-ETH dongle I didn't realize how slow it is.

jabrena commented

I say it but it is true that the solution is clean and it doesn´t require maintain process.
Next week, we will revew the whole installer. We can reopen this discussion :)