deb packages

[igrnt]

What's the situation with packaging Minimserver for Linux distributions, e.g. deb packages?
I read an old thread that this was planned, but also another thread about the licence terms prohibiting users from doing this.
I wanted a deb package for minimserver as part of developing another bit of software that would have minimserver as a dependency - hence it would be easy to install on a headless/no SSH system (that has a web GUI for installing packages from Apt repositories).

[simoncn]

(20-11-2015 09:51)igrnt Wrote:  What's the situation with packaging Minimserver for Linux distributions, e.g. deb packages?
I read an old thread that this was planned, but also another thread about the licence terms prohibiting users from doing this.
I wanted a deb package for minimserver as part of developing another bit of software that would have minimserver as a dependency - hence it would be easy to install on a headless/no SSH system (that has a web GUI for installing packages from Apt repositories).

Can you say more (by PM if you prefer) about the other software that would have MinimServer as a dependency?

[igrnt]

Yes, brevity in my first post was only for sake of clarity, not secrecy!

I'm talking about installing MinimServer on OpenMediaVault (http://www.openmediavault.org), which is a NAS solution built on Debian Linux. It has a web GUI and plugin system, via which users can install software. A plugin for a given program is basically just a bit of web page and code that allows the service (SysInitV) to be controlled and configured, but crucially it also installs the underlying programme by means of a dependency in the deb package. E.g. minidlna plugin depends on minidlna, so users install minidlna by installing the plugin.

Hence I could write a plugin for MinimServer on OMV, but it cannot currently install MinimServer as there is no deb package. Obviously in the case of MinimServer the plugin would be very basic, just showing the running status and allowing enable/disable, as configuration is done with MinimWatch. Also, a deb package for MinimServer would, I imagine, be low maintenance as once installed, MinimServer updates itself. However, it would be nice for ease of installation for users.
If you are concerned about the automated nature of this, and that it would not drive users to the MinimServercweb page, I was thinking to duplicate the PayPal donate button for MinimServer on the plugin's web page.

(Sorry, rather long-winded explanation for what is in reality rather simple!)

[simoncn]

(20-11-2015 10:45)igrnt Wrote:  Yes, brevity in my first post was only for sake of clarity, not secrecy!

I'm talking about installing MinimServer on OpenMediaVault (http://www.openmediavault.org), which is a NAS solution built on Debian Linux. It has a web GUI and plugin system, via which users can install software. A plugin for a given program is basically just a bit of web page and code that allows the service (SysInitV) to be controlled and configured, but crucially it also installs the underlying programme by means of a dependency in the deb package. E.g. minidlna plugin depends on minidlna, so users install minidlna by installing the plugin.

Hence I could write a plugin for MinimServer on OMV, but it cannot currently install MinimServer as there is no deb package. Obviously in the case of MinimServer the plugin would be very basic, just showing the running status and allowing enable/disable, as configuration is done with MinimWatch. Also, a deb package for MinimServer would, I imagine, be low maintenance as once installed, MinimServer updates itself. However, it would be nice for ease of installation for users.
If you are concerned about the automated nature of this, and that it would not drive users to the MinimServercweb page, I was thinking to duplicate the PayPal donate button for MinimServer on the plugin's web page.

(Sorry, rather long-winded explanation for what is in reality rather simple!)

MinimServer installs updates automatically but new releases are downloaded and installed manually by the user.

The current MinimServer Linux package manages SysInitV for enable/disable and I would be concerned about having a plugin attempting to manage this as well.

Is there some reason why an OpenMediaVault user couldn't use the current Linux installation package to install MinimServer?

I would not want the donate button for MinimServer to be duplicated. Instead, I would like (if possible) for the plugin installation to display the original MinimServer donate page. This is how the VortexBox installation of MinimServer works.

I think the next step would be for me to install OpenMediaVault and see how it works from a user perspective. I see there is a 2.0.15 install image for Raspberry Pi 2. Would this be suitable?

[igrnt]

The 2.0.15 Raspberry Pi image should be good. The latest (x86) is 2.1.18, but the differences are probably minor. And can probably be updated.

I will have a peek at how VortexBox does it.

There are two reasons for having a deb - ease of installation from the GUI (otherwise it involves SSH command line access), and automatic installation as a dependency.
It's not a showstopper to have to install MinimServer by hand, but it does limit the audience.

I will have to inspect the MinimServer installation script, but I don't see any conflict, as far as I'm aware it uses a pretty standard init script, and any plugins in OMV just call this with, e.g. stop, start as normal.

Finally, not sure I follow re installation of future releases - I installed MinimServer via SSH just once and have updated it via MinimWatch from my Windows client since then. I haven't paid too much attention to the version numbers but are you saying if there was a major release I would have to manually reinstall?

[simoncn]

(20-11-2015 18:56)igrnt Wrote:  The 2.0.15 Raspberry Pi image should be good. The latest (x86) is 2.1.18, but the differences are probably minor. And can probably be updated.

I will have a peek at how VortexBox does it.

There are two reasons for having a deb - ease of installation from the GUI (otherwise it involves SSH command line access), and automatic installation as a dependency.
It's not a showstopper to have to install MinimServer by hand, but it does limit the audience.

I will look at how the plugins work for other packages. Can you suggest anything similar for me to look at?

Quote:I will have to inspect the MinimServer installation script, but I don't see any conflict, as far as I'm aware it uses a pretty standard init script, and any plugins in OMV just call this with, e.g. stop, start as normal.

Are you intending that the plugin would directly manipulate the System V init files for MinimServer? This should only be done via the minimserver/bin/setup command.

Quote:Finally, not sure I follow re installation of future releases - I installed MinimServer via SSH just once and have updated it via MinimWatch from my Windows client since then. I haven't paid too much attention to the version numbers but are you saying if there was a major release I would have to manually reinstall?

For any kind of release (major or minor), the user would need to reinstall MinimServer. MinimWatch can install updates but not releases.

[igrnt]

(20-11-2015 21:43)simoncn Wrote:  I will look at how the plugins work for other packages. Can you suggest anything similar for me to look at?

Probably the minidlna plugin, as that is the closest thing to MinimServer.

Quote:Are you intending that the plugin would directly manipulate the System V init files for MinimServer? This should only be done via the minimserver/bin/setup command.

Manipulate, no, I'm just saying that is how the plugin would control MinimServer, by calling, e.g., 'service minimserver stop' or 'update-rc.d minimserver disable'. i.e. the standard SysInitV/Debian of controlling installed services.

Quote:For any kind of release (major or minor), the user would need to reinstall MinimServer. MinimWatch can install updates but not releases.

Ah, okay, I guess have never installed a new release of MinimServer then, only the updates. In this case, Debian packaging would be ideal, as new releases could be installed very easily/semi-automatically.

[igrnt]

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.

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

[igrnt]

(25-11-2015 18:11)simoncn Wrote:  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.

I understand your concerns, most importantly the extra work required. Note that I'm not asking you to create and maintain deb packages - I can and would have done this myself just for OMV, but I got the impression that the licence prohibits this. So my question is: would you be happy to allow this?

This immediately resolves your issues 1-4.
It should (would) also satisfy issue 5.
I don't consider issue 6 to be a problem - if an OMV user wanted to do this, they would be free to go 'off-piste', but the OMV plugin wouldn't support it. In any case, such a situation requires some customization, no? The init scripts don't start multiple instances, do they?

Of course, ultimately I will respect your wishes, and if I have to do it similar to the VortexBox way I will.