April 18, 201610 yr Version 6.2 betas are updated with a newer version of Slackware and some packages used by plugins are not compatible with 6.1.9 and 6.2. Can we add an unRaid version test to the plugin install so plugins can be made to be compatible with 6.1.9 and 6.2 plus future versions that update Slackware? The version test would allow conditional plugin processing based on the installed unRaid version. I had this issue with the unassigned devices plugin and I managed to do the conditional installation of the parted package, but it was more complicated than it needs to be. Here is the code I wrote to get the job done: <!-- parted-3.1-x86_64-1.txz (for unraid 6.1) --> <FILE Name="&packages;/parted-3.1-x86_64-1.txz"> <URL>"&gitURL;/packages/parted-3.1-x86_64-1.txz"</URL> <MD5>140283cca20483fcacd805201b33798a</MD5> </FILE> <!-- parted-3.2-x86_64-2.txz (for unraid 6.2) --> <FILE Name="&packages;/parted-3.2-x86_64-2.txz"> <URL>"&gitURL;/packages/parted-3.2-x86_64-2.txz"</URL> <MD5>1026cb6b665bbeff2d514d6510d00bc5</MD5> </FILE> <!-- The 'parted' package install script. --> <FILE Run="/usr/bin/php"> <INLINE> <![CDATA[ <? $version = parse_ini_file("/etc/unraid-version"); $plugin = "/boot/config/plugins/unassigned.devices/packages"; $command = "upgradepkg --install-new"; if ( version_compare($version['version'],"6.1.9", "<=") ) { $name = "$plugin/parted-3.1-x86_64-1.txz"; } else { $name = "$plugin/parted-3.2-x86_64-2.txz"; } shell_exec("logger plugin: running: $name") ; system("$command $name", $retval); if ($retval) { echo "run failed command: $command retval: $retval"; exit(1); } ?> ]]> </INLINE> </FILE> I also had to download both versions of parted, but only install the one for the running unRaid version.
April 18, 201610 yr CA does offer min ver and max ver tags in the templates so you could also accomplish this through two plugins and only the one which was compatible would display. Definitely not ideal but is another option Sent from my LG-D852 using Tapatalk
April 18, 201610 yr Author My choice is to maintain only one plugin that would handle the installation based on the unRaid version, rather than multiple plugin versions. We had that going on with the v5 to v6 transition and it was and still is messy. The user that does an installation manually will also create themselves a problem with the wrong choice. I appreciate your suggestion, but I would rather have a version check in the plugin installer.
April 18, 201610 yr I do it similar but in bash in the install script. Kanged from boniel or gfjardim or both. It would be nice if there were an unRAID version xml tag for <FILE> dependencies so not all packages had to be downloaded. <FILE Name="&plgPATH;/freeipmi-1.4.11-x86_64-3.txz"> <URL>&pkgURL;/freeipmi-1.4.11-x86_64-3.txz</URL> <MD5>6c7839886f7c7b0cc4947aaf6199d60e</MD5> </FILE> <FILE Name="&plgPATH;/freeipmi-1.5.1-x86_64-1.txz"> <URL>&pkgURL;/freeipmi-1.5.1-x86_64-1.txz</URL> <MD5>f9df6ccd8c231e937ac4a8459ae91330</MD5> </FILE> <!-- The 'install' script. --> <FILE Run="/bin/bash" Method="install"> <INLINE> #Verify unRAID Version source /etc/unraid-version VER=${version:0:3} CMD="upgradepkg --install-new" if [[ $VER == 6.0 ]]; then echo "unRAID version 6.1 or higher is required" exit 1 fi # Verify and install plugin package sum1=$(/usr/bin/md5sum &plgPATH;/&plgNAME;.txz) sum2=$(/usr/bin/cat &plgPATH;/&plgNAME;.md5) if [ "${sum1:0:32}" != "${sum2:0:32}" ]; then echo "Wrong 'plugin' package md5 hash." rm &plgPATH;/&plgNAME;.txz \ &plgPATH;/&plgNAME;.md5 exit 1 else if [[ $VER == 6.1 ]]; then echo "\nInstalling dependencies for unRAID 6.1" $CMD &plgPATH;/freeipmi-1.4.11-x86_64-3.txz fi if [[ $VER == 6.2 ]]; then echo "\nInstalling dependencies for unRAID 6.2" $CMD &plgPATH;/freeipmi-1.5.1-x86_64-1.txz fi $CMD &plgPATH;/&plgNAME;.txz
April 29, 201610 yr I propose the usage of the optional keywords "Min" and "Max". This would allow conditional installation of packages depending on the version of unRAID. The example of dlandon then would look like this: <!-- parted-3.1-x86_64-1.txz (for unraid 6.1) --> <FILE Name="&packages;/parted-3.1-x86_64-1.txz" [color=red]Min="6.0.0" Max="6.1.9"[/color]> <URL>"&gitURL;/packages/parted-3.1-x86_64-1.txz"</URL> <MD5>140283cca20483fcacd805201b33798a</MD5> </FILE> <!-- parted-3.2-x86_64-2.txz (for unraid 6.2) --> <FILE Name="&packages;/parted-3.2-x86_64-2.txz" [color=red]Min="6.2.0"[/color]> <URL>"&gitURL;/packages/parted-3.2-x86_64-2.txz"</URL> <MD5>1026cb6b665bbeff2d514d6510d00bc5</MD5> </FILE> Notes: - When no "Min" and no "Max" are given then no unRAID version dependency check is done (current implementation) - When only "Min" is given then unRAID versions starting at "Min" or higher are accepted - When only "Max" is given then unRAID versions up to "Max" are accepted - When both "Min" and "Max" are given then unRAID versions from "Min" up to "Max" are accepted What do you think?
April 29, 201610 yr Author I propose the usage of the optional keywords "Min" and "Max". This would allow conditional installation of packages depending on the version of unRAID. The example of dlandon then would look like this: <!-- parted-3.1-x86_64-1.txz (for unraid 6.1) --> <FILE Name="&packages;/parted-3.1-x86_64-1.txz" [color=red]Min="6.0.0" Max="6.1.9"[/color]> <URL>"&gitURL;/packages/parted-3.1-x86_64-1.txz"</URL> <MD5>140283cca20483fcacd805201b33798a</MD5> </FILE> <!-- parted-3.2-x86_64-2.txz (for unraid 6.2) --> <FILE Name="&packages;/parted-3.2-x86_64-2.txz" [color=red]Min="6.2.0"[/color]> <URL>"&gitURL;/packages/parted-3.2-x86_64-2.txz"</URL> <MD5>1026cb6b665bbeff2d514d6510d00bc5</MD5> </FILE> Notes: - When no "Min" and no "Max" are given then no unRAID version dependency check is done (current implementation) - When only "Min" is given then unRAID versions starting at "Min" or higher are accepted - When only "Max" is given then unRAID versions up to "Max" are accepted - When both "Min" and "Max" are given then unRAID versions from "Min" up to "Max" are accepted What do you think? I like it a lot. Even better than my idea. What about backwards compatibility? What would happen in older versions when the plugin is installed without an update to unraid?
April 29, 201610 yr What about backwards compatibility? What would happen in older versions when the plugin is installed without an update to unraid? Older plugins won't have the "Min" and "Max" defined, meaning there won't be a unRAID version check done. Older versions of unRAID will simply ignore the new keywords.
April 29, 201610 yr What about backwards compatibility? What would happen in older versions when the plugin is installed without an update to unraid? Older plugins won't have the "Min" and "Max" defined, meaning there won't be a unRAID version check done. I think what he meant was how will the package installer handle Min on older versions of unRAID? Would it error? I just added it to a plg file and it downloaded and installed the file fine with Min="6.2.0" inside the <FILE > tag with no error. Btw I like the idea.
April 29, 201610 yr Yeah, I misread the question and posted an update "older unRAID versions simply ignore the new keywords".
April 29, 201610 yr Author What about backwards compatibility? What would happen in older versions when the plugin is installed without an update to unraid? Older plugins won't have the "Min" and "Max" defined, meaning there won't be a unRAID version check done. I think what he meant was how will the package installer handle Min on older versions of unRAID? Would it error? I just added it to a plg file and it downloaded and installed the file fine with Min="6.2.0" inside the <FILE > tag with no error. Btw I like the idea. Yes, my concern is the plugin install would error out and the installation not complete with the 'Min' and 'Max' tags. dmacias's test seems to imply that it would just be ignored, but without the version test in older versions it seems to not work the way we want. I would think that at least 6.1 and 6.2 should do the test.
April 29, 201610 yr What about backwards compatibility? What would happen in older versions when the plugin is installed without an update to unraid? Older plugins won't have the "Min" and "Max" defined, meaning there won't be a unRAID version check done. I think what he meant was how will the package installer handle Min on older versions of unRAID? Would it error? I just added it to a plg file and it downloaded and installed the file fine with Min="6.2.0" inside the <FILE > tag with no error. Btw I like the idea. Yes, my concern is the plugin install would error out and the installation not complete with the 'Min' and 'Max' tags. dmacias's test seems to imply that it would just be ignored, but without the version test in older versions it seems to not work the way we want. I would think that at least 6.1 and 6.2 should do the test. Any "unknown" keywords are simply ignored by the plugin manager, it won't error out. The proposed changes can be submitted for both unRAID 6.1 and 6.2 trains, but up to LT to decide on the actual updates.
April 29, 201610 yr Author On older versions without the 'Min' and 'Max' version check, the first package would install and then the second package would install and update the first package version and we're back to the original problem with the updated package being installed on an older version. It would have to implemented on 6.1 and 6.2 to be effective. Let's see if LT thinks it's worth an update.
May 1, 201610 yr I have also added the "min" and "max" attributes to the plugin itself, which allows conditional installation of the complete plugin depending on the unRAID version. Below an example: <PLUGIN name="&name;" author="&author;" version="&version;" launch="&launch;" pluginURL="&pluginURL;" [color=red]min="6.0.0" max="6.1.9"[/color]> This works independent of the attributes given to the <FILE> statements, e.g. in the same plugin one could do: <!-- SOURCE PACKAGE --> <FILE Name="&source;.txz" Run="upgradepkg --install-new --reinstall" [color=red]Max="6.2.0"[/color]> <URL>https://raw.githubusercontent.com/bergware/dynamix/master/archive/&name;.txz</URL> <MD5>&MD5;</MD5> </FILE> Note the capitalization of the words under <FILE>
Archived
This topic is now archived and is closed to further replies.