deb packages

[simoncn]

(22-11-2015 17:42)igrnt Wrote:  Okay, I downloaded VortexBox and had a quick play, and looked at the MinimServer setup script too.
I didn't know about the :9790 interface that MinimServer exposes - the plugin could integrate (display) that too.

The VortexBox user experience is similar in that the user clicks the install button to install MinimServer, but I see that it differs for MinimServer in that it opens the MinimServer download web page directly and then passes the URL back to a script to download and install it automatically.
A plugin for OMV couldn't directly replicate the VortexBox method of forcing the user to click themselves before installation progresses, I guess the closest thing would be to show something similar post-installation: OMV plugins (normally) install services in a disabled state, so that the user must enable the service from the web GUI before it runs (e.g. install the minidlna plugin, then go to the DLNA service settings page, it is disabled/not running). Therefore, a MinimServer plugin settings page could display a 'first run' page that would be the MinimServer donate-popup page. Users would click Trial/donate/no donate before the plugin settings page would load allowing them to enable it.

I don't understand why the VortexBox approach wouldn't work for an OMV plugin. The OMV page would load the MinimServer page (passing the download type that it wants) and the MinimServer page would prompt the user and then invoke the OMV page with the correct URL for download. If the user doesn't click one of the buttons on the MinimServer page, the installation wouldn't happen.

I have some other concerns about creating .deb packages that duplicate the contents of the current .tar.gz packages:

1) The current packaging structure of MinimServer (code and configuration data in the same parent folder) is not the usual structure of a .deb package.

2) As well as the initial effort required to develop the .deb package, I would need need to build and test 5 more downloads every time there is a new release. This is a significant amount of extra work.

3) Having two different packages available for Debian Linux (.deb and .tar.gz) would be confusing for users as it wouldn't be clear which one they should use. It would also require me to create and maintain duplicate documentation covering these two options.

4) The current .tar.gz package is intentionally not tied to Debian. This was a deliberate choice to enable MinimServer to be installed on a wide range of Linux distributions . If I produce a Debian-specific package, users of other distributions will want specific packages for these distributions as well.

5) The minimserver/bin/update command enables the user to install a new release without losing his/her configuration and installed extensions. It's not clear how this would be supported if the user installs a new version of the .deb package. (This is related to point 1.)

6) The minimserver/bin scripts support installing and running multiple instances of MinimServer in different directories. This couldn't easily be done with a .deb package because this would install MinimServer in a specific directory.

It might be possible to find solutions for all the above (and any more that might come up) but I don't have the bandwidth at the present time to spend on this. Instead, I would like to ask you to consider whether your OMV plugin could download and unpack the .tar.gz package instead of using the .deb dependency mechanism to download MinimServer. This is what VortexBox is doing.