Debian installer

[darkdragon-001]

Install4J supports creation of Debian installer (.deb). Could you please generate such an installer to facilitate installation on Linux?

[raztoki]

linux does have a installer with bash script. but deb package would make it more idiot proof or should I say user friendly =]

[Jiaz]

We don't have deb package at the moment and I don't think that a install4j deb variant would be good because the standalone installer is *standalone* while I think a deb package should make use the package system and make use of it to install/use java while the *standalone* installer comes with bundled java.

I would prefer to have a native deb package that tells to hava java installed and then just downloads the files from server
and installs them to the right places and installs links to startmenu. Help on creating such a deb package is welcome but I really don't think
that install4j is the right choice for it

[darkdragon-001]

First of all, make sure JD2 is compatible with latest OpenJDK11 which is default on latest OSes. When I tried to run with Java11, I got the following warning:

WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.appwork.shutdown.ShutdownController (file:/home/USER/jd2/JDownloader.jar) to field java.lang.ApplicationShutdownHooks.hooks
WARNING: Please consider reporting this to the maintainers of org.appwork.shutdown.ShutdownController
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

---

Install4j automatically searches for system java versions. So maybe adding an option in the installer not to install the bundled java version would be a good start.
Further, java version requirements should be relaxed (currently only 1.6 to 2.0).

---

I don't know too much about java build systems nor how your source files need to be assembled together.
General debian packaging is quite straight-forward though:

1. Put all source files in a folder jd2-0.1 (where 0.1 is the version)
2. Create upstream source package: tar czvf jd2-0.1.tar.gz jd2-0.1
3. Run debmake in jd2-0.1 to create a sample "debian" folder
4. Depending on your build system, follow the Javahelper **External links are only visible to Support Staff**guide (Ant, Maven, Gradle) and **External links are only visible to Support Staff**tutorial (no build system; scroll to the end for examples)
5. Build and package via "debuild -b --no-sign"

---

Further, I think the (debian) installer should not download source files, but instead every update should just create a new version. Since hoster-plugins change very often, they should be packaged separately (single SOURCE, multiple PACKAGE in control: **External links are only visible to Support Staff****External links are only visible to Support Staff**).

[Jiaz]

JDownloader is compatible with Java 1.6 up to Java 14. Those warnings are normal as some *workarounds*/*tricks* we make use of, no longer work/are compatible with newer Java versions.

[Jiaz]

I'm sorry but in case we provide a deb package, it will be very similiar to current installation process. It will contain the start/neccessary parts that are required for self update of JDownloader that finally installs the correct version for current OS/OS-bitness/CPU/CPU-bitness/evironment.

We won't have a 2nd deployment system in parallel use. Deb packages don't support incremental updates/background updates. JDownloader supports nearly 8 thousand different sites and heavily depends on an update system that supports those features. It's not feasible to have several thousand deb packages to reduce update traffic and packaging plugins into one big deb will require vast amounts of traffic

[Jiaz]

Originally Posted by darkdragon-001

Install4j automatically searches for system java versions. So maybe adding an option in the installer not to install the bundled java version would be a good start.

The current install4j installer already requires Java to run as we make heavily use of it. Reusing system java fails when it's different bitness. Can't use 32bit system java on 64bit executable and vice versa. Most Win/Mac systems don't have java installed in system.

Once we rebuild/work on installers, we will provide installers that bundle java and versions that make use of system java if available or download if required.

[darkdragon-001]

Originally Posted by Jiaz

Once we rebuild/work on installers, we will provide installers that bundle java and versions that make use of system java if available or download if required.

Looking forward to this!

---

If you tell me how your JDownloader.jar installer is built, I could help you with the package.

[Jiaz]

@darkdragon-001: I don't see why the *how* is important? JDownloader.jar is build via ant script

Feel free to contact me in chat (irc, freenode, #jdteam) or via support@jdownloader.org if you have questions/want to talk about this.

[darkdragon-001]

Source packages are preferred over binary packages. Therefor building the jar as part of the packaging process would be better. This also allows rebuilds for new distribution versions etc.

Is it possible to tell the jar that it should use a different working directory?
Debian packages will install e.g. in /etc/share/jdownloader2 where root access is required. So updating needs root, while running the application should not be done as root! So telling the jar, to download/update files in the user's home folder ~/.jdownloader2 would be recommended.

[Jiaz]

Originally Posted by darkdragon-001

Source packages are preferred over binary packages. Therefor building the jar as part of the packaging process would be better.

I'm sorry but that's not possible. For example the update system is not part of the open source. Doesn't make any sense in connecting a self/3rd party compiled version
to the official release. Also there are non open source parts like key material.

Originally Posted by darkdragon-001

Is it possible to tell the jar that it should use a different working directory?
So telling the jar, to download/update files in the user's home folder ~/.jdownloader2 would be recommended.

That's not possible/supported and there are not plans to change this.
JDownloader is supporting many different OS/CPU.. and we don't do special stuff for each combination.
JDownloader works exactly the same on every OS/CPU.... Each user must have it's own installation

[darkdragon-001]

I'm sorry but that's not possible. For example the update system is not part of the open source. Doesn't make any sense in connecting a self/3rd party compiled version
to the official release. Also there are non open source parts like key material.

You are not completely open source?
If no working version of JDownloader can be built using the published source code, then your statements about an open source download manager are misleading!

That's not possible/supported and there are not plans to change this.
JDownloader is supporting many different OS/CPU.. and we don't do special stuff for each combination.
JDownloader works exactly the same on every OS/CPU.... Each user must have it's own installation

I thought having a single system JDownloader.jar and having all other file installed for the user might work. If there is no constant component, then creating a Debian package is not possible.

[Jiaz]

Originally Posted by darkdragon-001

I thought having a single system JDownloader.jar and having all other file installed for the user might work. If there is no constant component, then creating a Debian package is not possible.

JDownloader.jar itself only contains mainly the update client and base dependencies. That's why it is enough to have this file to install/fix a JDownloader installation. The client first updates itself (JDownloader.jar) and then installs/updates JDownloader.

Originally Posted by darkdragon-001

if there is no constant component, then creating a Debian package is not possible.

I agree and I really would prefer an updated Install4J installer for GUI users and maybe sort of installation/helper script for headless/server users.

[Jiaz]

Originally Posted by darkdragon-001

If no working version of JDownloader can be built using the published source code, then your statements about an open source download manager are misleading!

That's not what I wrote. The non closed source parts are not required to build/run JDownloader.

[darkdragon-001]

Originally Posted by Jiaz

The client first updates itself (JDownloader.jar) and then installs/updates JDownloader.

I agree and I really would prefer an updated Install4J installer for GUI users and maybe sort of installation/helper script for headless/server users.

Adding run arguments to only update and not start JDownloader would allow creating such an installation/helper script as discussed here.

[Jiaz]

Originally Posted by darkdragon-001

Adding run arguments to only update and not start JDownloader would allow creating such an installation/helper script as discussed here.

I completely agree on this and it makes indeed perfect sense to have such a *install/setup* parameter available. Maybe even one step further to specify sort of *setup configuration* and then read *install to*, *basic setup information like download folder...* and *username/password*. such a file can be genrated by script/tools then and makes it much easier to install JDownloader in headless/docker/xy environments

[Jiaz]

btw, feel free to join chat (irc, freenode, #jdteam) if oyu want to talk about this in live

[darkdragon-001]

I was thinking again about the debian installer: The only parts which change very often are the plugins/hosters, right? The base program doesn't change this often. So maybe it makes sense to separate this? The debian installer could install installes the program without the plugins, on every startup the plugins are downloaded/updated?

[raztoki]

it highly depends,
core changes can also be multiple times a day.
Updates that require client restart == core.
So you can tell when and how often this takes place.
Plugin updates are silent, and do not require client restart.

[darkdragon-001]

Originally Posted by raztoki

core changes can also be multiple times a day.

I guess a client would still work for several weeks/months/years with only plugin/hoster updates (since plugin API changes would require all plugins to change as well and thus probably don't happen very often). Thus splitting core updates and plugin updates would allow to distribute the core via debian package and the plugins on startup.

[raztoki]

Not quite the case. It highly depends on the plugin of course.
But update system does become blocked to pushing plugin updates due to core update dependencies. This then prevents all plugin updates being distributed, even though other plugins are not calling dependancy.

tbh I don't believe Appwork is not going to change the way JD is delivered or packaged. basically nothing major has changed in jd2 for many years. I would not get your hopes up.