Plugin Manager

[zoggy]

Where are you getting this MD5 from?  If it is from the same editable-by-all plug-in page you have only proven that you downloaded the correct malware package.

 

Ideally, the md5s should be held on a different site from the data, separately controlled.

 

no need to go crazy, but you can do an approach like unmenu where the 'file list' has the md5 + packages listed out. just need to have something that keeps track of the changes/version differences/etc. the problem with a 'wiki' is that its tied to the rest of the site/ive seen unraid's webserver become unresponsive about once each weekend.. ideally this should be put onto github/googlecode/sourceforge/launchpad/etc where they have redundancy/backups/mirrors/etc already worked out to ensure uptime.

 

about md5 hashing, you could extend this one step further and do a digest file for each package like syno's community does:

subversion-1.7.8.tar.bz2 SHA1 12c7d8d5414bba74c9777c4d1dae74f152df63c2
subversion-1.7.8.tar.bz2 SHA256 fc83d4d98ccea8b7bfa8f5c20fff545c8baa7d035db930977550c51c6ca23686
subversion-1.7.8.tar.bz2 MD5 454b9f398415c3504435bf8c3f6ed127

 

now there is two main approaches to package installers so far with unraid.. unmenu's approach where you use official slackware ones.. or SF's approach where you make the installer. both have their pro and cons.

 

SF pro: if you need to update/patch/customize the package.. its easy to do so. since you control it

SF con: you have to worry about where to host it/trust others -- no moderation.

 

unmenu pro: official packages are installed by a lot of people already.. so if there are bugs/issues they are probably known. plus these are already hosted by mirrors.

unmenu con: since you are waiting for other people to make packages.. its a hit and miss if they have what you want or have it upto date.. since they are usually made around the slackware disto's release..

 

then once you actual figure out the package to install.. it comes down to the 3 basic types of packages:

 

[*]those you can just install via installpkg

[*]those you have to build from source

[*]a then there are patches to an existing package (diff)

 

handling those is the first step.. then what about configuring the package post install? that's the cumbersome part in unmenu where there's not really an elegant way to code this from a developers perspective. its a whole bunch of bash-fu and testing.

 

and then to make this even more complex.. what about those that don't use x86 cpu? or what about packages you want others to 'test' or private ones?

[limetech]

I split off zoggy's post to a new topic, seemed like a logical place to start.

 

Let's talk about how this should work.  Please keep on-topic 

[bmfrosty]

Having just started using this, I'm not going to comment on unmenu, but I think I see this as 3 or 4 distinct things.

 

1.  A repo for pkg and plg files.  Ultimately this should be a slackware repo to match the unraid version.  This will also include an index file that links to all the PLG files.  The PLG files link to the PKG files in the repo.  This repo is important because PKG files tend to disappear, even for plugins 5 or 6 months old.

2.  A second repo for checksum files.  If I download ffmpeg-gui.plg from the first repo, I should automatically download ffmpeg-gui.md5 (or sha1 or sha256 or all 3) from this repo.  Same goes for the PKG files I download.  This is important because a single repo if compromised means that changes to package, plugins, and the checksums that verify them.

3.  A PLG management and review process.  This is important.  My example is going to be sshd.  overbyrn's sshd plugin is incompatible with one of the simple features plugins.  They both want competing versions of openssl.  Different members of this team should be responsible for the two repos.  No 1 person should have access to change both.

4.  An automated process to publish changes to either repo.  This does a double duty.

      a) It allows those interested to follow changes.

      b) It allows for an additional check against package/plugin/md5 changes.  Grabbing the entire md5 repo hourly/daily/whateverly and then publishing checksums of that repo and comparing them to the previous days should protect against malicious changes.  This should be an open enough process that anyone should be able to replicate it and independently verify that a repo stays the same.

 

Whatever it is, it should be attached to some hosting service.  Amazon S3 is probably a good 1st, and then something else for the 2nd repo. 

 

Just thoughts.

[overbyrn]

My example is going to be sshd.  overbyrn's sshd plugin is incompatible with one of the simple features plugins.  They both want competing versions of openssl.

Poor example.  My plugin is 100% compatible with SimpleFeatures.  I don't even use openssl.

 

[Orbi]

My example is going to be sshd.  overbyrn's sshd plugin is incompatible with one of the simple features plugins.  They both want competing versions of openssl.

Poor example.  My plugin is 100% compatible with SimpleFeatures.  I don't even use openssl.

 

A better example (I hope): Sabnzbd installs openssl-0.9.8r-i486-3 and simplefeatures installs openssl-1.0.1c-i486-3, resulting in SF gui instability while using sabnzbd. After removing openssl 0.9.8 from the sabnzbd.plg and package folder and restarting the server, SF gui remains responsive.

 

http://lime-technology.com/forum/index.php?topic=12698.msg231583#msg231583

[NAS]

Plugins should not be explicitly defining package versions to install. I know there is a case to be made that they should be able to but if we go that route things WILL break and likely often. If a package needs some specific version of a package and only that version then it should be in an experimental repo and not listed with the others.

 

There should and needs to be a way for packages to list dependencies based on a global slackware branch variable

 

i.e. get latest openssl from slackware 13.1 branch

 

and not

 

get this openssl from this url

 

I would suggest the obvious step would be for limetech to host the packages and not reply on some 3rd party repo. This in itself bring a load of benefits although and introduces a peer review step even if its just "limetech please add xxx to repo"

[zoggy]

i think the plugin discussion is getting muddled with the concept of a plugin manager and a package repo.

 

first thing we should do is focus on a plugin manager (installer) part where we can install local or remote packages (via url).

the method for limiting where packages can be installed from can come later. if you want to take it in house.. or have a package list thats moderated.. or whatever.

 

about the plugin/package installer.. the main thing that comes into play is something that is reliable.. can deal with multiple mirrors? retry if there are network issues? handle dependencies for other packages/requirements? rollback? logging? Support for http, ftp, rsync, and local filesystems?

 

what foundation does unraid have already that can/should be use.. can we leverage something built into the os already?

 

do we code something that uses python? ruby? bash?

 

I personally don't know ruby so I would lean towards bash (unmenu's approach).. or python (but python isnt included.. and if we include it we do 2.x or 3.x.. I'd say 2.6.x and then we could use libs to do a lot of the grunt work, ex: Requests - http://docs.python-requests.org/en/latest/ )

 

Looking into slackware's package management options:

 

A simple tgz package system combines the standard tar and gzip. Used by Slackware Linux and its closer derivates, there are a few higher-level tools that use the same tgz packaging format, including: slapt-get, slackpkg, zendo, netpkg, and swaret.

 

The two that caught my eye are:

 

http://en.wikipedia.org/wiki/Slapt-get

-- slapt-get builds functionality on top of the native Slackware package tools (installpkg, upgradepkg and removepkg) enabling package query, remote fetching, system updates, integrated changelog information, and many optional advanced features such as dependency resolution, package conflicts, suggestions, checksum and public key verification, and transfer resumption.

-- slapt-get uses the libcurl cURL library for transport. libcurl provides support for ftp, ftps, http, https, file:// and other resource types along with transfer resume for incomplete downloads. slapt-get also uses the GNU Privacy Guard library to validate signatures.

-- slapt-get works with official Slackware mirrors and third party package repositories such as http://www.linuxpackages.net and http://www.slacky.eu/. slapt-get looks for support files, PACKAGES.TXT and CHECKSUMS.md5, in the repository for package information.

-- supports multiple package sources (including linuxpackages.net) with the ability to assign priorities to each source.

-- i18n support via GNU gettext with 26 language translations

 

http://en.wikipedia.org/wiki/Slackpkg

-- slackpkg is an automated package management tool written for Slackware as a shell script, like Swaret. However, Slackpkg does not resolve dependencies between packages.

 

As you can see.. slapt-get is looking better and better. So if we just created a shell wrapper that uses slapt-get we may be golden?

Looks like some people have already tried slapt-get out with unraid: http://lime-technology.com/forum/index.php?topic=28140.15

 

Then also from the slapt-get guys, cpan2tgz is a utility to create Slackware packages from CPAN Perl module distributions. I know there are a few people that may enjoy that.

 

Was curious about the dependency support in slapt-get, on their FAQ I see:

 

http://software.jaos.org/git/slapt-get/plain/FAQ.html#slgFAQ10

First of all, slapt-get does not provide dependency resolution for vanilla

Slackware packages (ie, official Slackware packages that come with the

distribution).

 

However, slapt-get does provide a framework for dependency resolution for

packages that follow the Slackware package format, while still being backwards

compatible.  This information is stored in so called meta files within the

package.  slapt-get does not parse the packages themselves.  It uses the

PACKAGES.TXT package database that Patrick Volkerding provides along with his

packages.  slapt-get uses this file by extending it with optional extra fields.

This information is stored within the package simply as a means of easy

transport, to later be parsed into a PACKAGES.TXT.

 

So looks like we would have to create a PACKAGES.TXT to add the dependency support..

http://software.jaos.org/git/slapt-get/plain/FAQ.html#slgFAQ17

 

some notes why dependency support isnt built into the default package manager:

http://docs.slackware.com/slackware:faq#why_doesn_t_slackware_s_package_manager_do_dependency_handling

 

 

[syntaxx]

Have you guys seen pfsense plugin/package manager? Maybe you can get some ideas from there. They host their own packages each author has access to their repo. Now if you are worrying about the hashes you can get the hash from a different repo since each package version are having the same hashes so you shouldn't worry about anything. Secondly when it comes to dependencies each plugin author should coordinate with each other incase they use the same dependencies. One thing to add if its possible maybe switch to another linux distro that has package manager, that way you can use apt-get or yum those dependencies without hesitation. And since most of the package are from source the plugin manager can just execute ./configure --blah --blah in just one click since all build-essentials are there it should be easy but it should have a dependency checker in place.

 

Just my 2 cents.

[bmfrosty]

My example is going to be sshd.  overbyrn's sshd plugin is incompatible with one of the simple features plugins.  They both want competing versions of openssl.

Poor example.  My plugin is 100% compatible with SimpleFeatures.  I don't even use openssl.

That's strange.  I got your SSHd package to work stably by removing one of the simplefeatures plugins.  I think it was the itunes/whatever plugin from simplefeatures.  I did not note it down, I just deleted the plugin since I wasn't going to use it. 

[limetech]

Package Mirror

 

There are numerous slack mirrors.  The one I've used for several years is hosted by Univ. of Utah:

http://slackware.cs.utah.edu/pub/slackware/

Always up and fast.

 

Dependencies

 

I don't really see why there should be an issue with dependencies.  As a plugin developer you must have a server with which to test.  If your plugin is developed in isolation, that is, on a stock unRaid distro without any other plugins installed, then you will quickly find out what package dependencies there are and make entries in your plg file to download them.

 

Now that you know which slack packages are needed, they should be taken from slack 13.1.  If every plugin author did this, then automatically the smallest set of slack packages will exist in the /boot/packages directory for the set of plugins installed by the user.

 

Trouble comes when plugin author uses a slack package newer than 13.1; then there's the possibility of two conflicting packages.  The installplg script tries to address this somewhat by using 'upgradepkg' but that is not always 100% reliable.

 

Sidebar: at some point there will be a 'prune' command added that can be invoked any time, but probably invoked by 'rc.local' after installing packages from /boot/extra, and by 'installplg' just before exit.  What 'prune' does is delete a number of known directories of files unneeded in an unRaid environment, e.g., 'man' files and other documentation included with packages.  Why do this?  Remember our root file system is in RAM and those files needlessly consume it, and it can add up to several megabytes+ very quickly.

 

What I'm concerned with is this: I don't want unRaid to grow into a general-purpose platform like ubuntu.  It should remain a storage platform.

 

Repository

 

I think this is a more pressing issue mainly because of the possibility of hacking.  The idea of the plugin wiki page is to simply serve as a central index of plugins that exist.  The current Plugin manager just goes and fetches that page, isolates the HTML <table>, and manipulates the "version" column to offer the user download/install/uninstall links.  It does this by comparing the version of the plugin in the wiki table against the version of the plg file already downloaded (if it already exists).  Right this is not secure.

 

One thing I don't want to do is host a plugin repository.  This is because merely hosting the code can, in some eyes, be lending at least tacit approval to their functionality.

 

So how to make for an easy user experience, but have the actual plugin code be distributed and secure?

[NAS]

Three simple points:

 

The XBMC addon specification and specifically OpenELEC implementation of it would cover every base we could think of. Possibly overkill but you dont want to have to revist this again next year (as they did).

 

Even within a single 13.1 repository you will in time have mismatched package versions as old are replaced with new.... and with that you are right back to where you started dealing with possible conflicts. This is not a problem that can be trivialised as it means proper use of the entire design spec can result in unp0redictable outages and behaviour. No one want this.

 

We MUST at a minimum be able to actively push out security fixes to slackware packages in a timely manner.

[limetech]

Three simple points:

 

The XBMC addon specification and specifically OpenELEC implementation of it would cover every base we could think of. Possibly overkill but you dont want to have to revist this again next year (as they did).

Link?

 

Even within a single 13.1 repository you will in time have mismatched package versions as old are replaced with new.... and with that you are right back to where you started dealing with possible conflicts. This is not a problem that can be trivialised as it means proper use of the entire design spec can result in unp0redictable outages and behaviour. No one want this.

I don't think a slack repository for a particular release changes post-release.  Slack 14.1 is imminent and I'll migrate unRaid OS to it.  But maybe we can solve it like this: instead of specifying the entire name-<version> of a slack package, specify just the <name> and 'installplg' will look at slack 13.1 (or 14.1 or whichever) to check for the latest version of that package, and download and/or replace the one in /boot/packages.

 

We MUST at a minimum be able to actively push out security fixes to slackware packages in a timely manner.

Ok, but the plugin itself is a far bigger security hole than just about any "security fix" in a package would be.

[zoggy]

Tom, is there a reason why you recommend using slackware 13.1 over newer packages (I've had no problems installing newer packages myself)?

 

Released: Wed May 19 04:40:19 UTC 2010

Here are some versions of major components of Slackware 13.1:

 

- Linux kernel          2.6.33.4

- C compiler            gcc-4.4.4

- Binutils              2.20.51.0.8

- GNU C Library          glibc-2.11.1

- X Window System        Updated (but not "bleeding edge") packages from X.Org

- KDE                    4.4.3

- Xfce                  4.6.1

 

From the slackware 13.1 repo:

[pre]python-2.6.4-i486-1.txz 06-Dec-2009 03:21 11M

openssl-0.9.8n-i486-1.txz 30-Mar-2010 00:34 2.2M

php-5.2.13-i486-2.txz 29-Mar-2010 01:45 3.2M[/pre]

 

From the slackware-current repo:

[pre]python-2.7.5-i486-1.txz 29-May-2013 08:29 11M

openssl-1.0.1e-i486-1.txz 12-Feb-2013 00:58 2.8M

php-5.4.17-i486-1.txz 16-Jul-2013 05:52 6.9M[/pre]

[warhead]

But maybe we can solve it like this: instead of specifying the entire name-<version> of a slack package, specify just the <name> and 'installplg' will look at slack 13.1 (or 14.1 or whichever) to check for the latest version of that package, and download and/or replace the one in /boot/packages.

 

Problem this introduces is complicated bug finding and you make it almost impossible to 'replicate' an install. Eg. I install package XYZ and it works fine on my system and I'm trying to help someone install it 3 months from now but the package version changes at the repo and introduces a small bug.

What works on this install might not work next week if there's a broken version uploaded to the repo.

 

I ran into this kind of problem with doing Fedora respins a little while ago. Out of the blue the livecds I make no longer install RAID configurations from the kickstart file and the system would hang part way through the install process. I finally isolated it down to a specific version of udev that got pushed into the repo.

 

I think what might work would be a way for packages to be downloaded straight from repo like you suggested, but also a way for the plugin manifest itself to specify the exact version of a package it requires as a "safe mode install" of sorts.

[zoggy]

I personally dont like the install 'whatever' version it finds approach. For some things that may work okay.. but for most of us nerds.. we want a specific version or better... and with regards to certain apps they need a specific version or better.. for example Sickbeard/Sabnzbd need python 2.5+, python 3.x doesnt work. But then there are forks of sickbeard that need python 2.6+.. 

 

Anyways, slapt-get has a dependency model that closely follows how nodejs works..

 

   PACKAGE NAME:  man-1.5l-i386-1.tgz
   PACKAGE MIRROR:  http://www.slackware.at/data/slackware-9.1/
   PACKAGE LOCATION:  ./slackware/ap
   PACKAGE SIZE (compressed):  166 K
   PACKAGE SIZE (uncompressed):  390 K
   PACKAGE REQUIRED: groff >= 1.56-noarch-1,man-pages | man-pages-de
   PACKAGE CONFLICTS:  
   PACKAGE SUGGESTS: 

The REQUIRED line is an addition supported by slapt-get, along with CONFLICTS

and SUGGESTS.  The meta files supporting dependencies, conflicts, and

suggestions are within the packages inside the ./install/ directory.  The

REQUIRED information is stored in the slack-required file.  The CONFLICTS

information is stored within the slack-conflicts file.  The SUGGESTS

information is stored in the slack-suggests file.  See FAQ #19 for a breakdown

of the structure of REQUIRED, FAQ #31 for CONFLICTS, and FAQ #44 for SUGGESTS.

MIRROR is an optional location so that the packages can be hosted elsewhere

(this is the internal representation slapt-get uses after caching the package

date from the remote package source).

 

This information is added to the PACKAGES.TXT file by extracting it from the

meta files within the package.  This is normally done by the provider of the

packages when they generate the PACKAGES.TXT support file for their package

source.  See FAQ #17 for an example script to generate an extended PACKAGES.TXT

file.

 

The inclusion of this information within the Slackware package format does not

inhibit the ability for Slackware pkgtools to install these packages.  This

information is silently ignored and discarded after the package is installed.

 

spksrc (synology community's package thing) have an interesting approach, they have a package dependency and what packages this is a dependency:

example: https://github.com/SynoCommunity/spksrc/blob/develop/spk/git-server/Makefile

 

the package needs 'git' installed and newer than 1.8.2.

then listed is all the packages that need this to work.. (dropbear, mktemp, busybox)

DEPENDS = cross/dropbear cross/mktemp cross/busybox
SPK_DEPENDS = "git>1.8.2"

 

this approach can get pretty messy and requires constant updating..  the dependency thing is going to be a pain no matter what.

 

I thought about coming up with my own dependency builder..

so lets take sickbeard for example (it needs Python 2.5+ and Cheetah 2.1.0+). sickbeard would list 'cheetah' as a dependency.. cheetah is a python plugin.. it would list python as a dependency.. thus python gets installed.. then cheetah.. then sickbeard. everyone is happy and the correct order of install is maintained. 

 

so what the plugin manager would need to do is take the list of all its packages.. look at all its dependencies and expand those out to get the full list of all the dependencies.. and flag any known conflicting things like two versions of the same lib..  how to resolve the dependency concern is going to be another big debate i'm sure.

 

but honestly this whole mess 'shouldnt' happen too much as people should not be installing everything in the world to make it a normal linux distro.. and the actual conflicts probably could be resolved pretty easily by just agreeing on a common subset.. or handling them on a case by case bases.

 

some food for thought,

 

In unmenu, there are various package types created over the years... there are some packages that install the dependencies it needs on its own.. so package x will install x,y,z. This approach works well for one package. But if each package did this.. there can be conflicts/issues/adds extra code to test and catch for things. This causes the package to be larger, harder to maintain across the board as the package dependencies are buried within the package. Over time Joe tried to move towards a 1 item per package rule.. this results in quite a few extra one off packages (while small) clutters the plugin lists. So for example there is one for python, one for python-cheetah, etc. Then there is a variant of this where the Perl package has an option in it to install a CPAN plugin.. instead of a separate package for the cpan module.

 

[NAS]

IMHO there is a perception change we need to make. In old versions of unRAID we would have a line in the sand that everyone had. My version would match your version unless one of us manaully went and done something. Then came about plugins but again if no messed about we would match.

 

That is not the case any more. If we are allowing people to enhance unRAID to this extent we have to maintain ALL dependencies with at least security fixes. The easiest way to do this is to keep all dependencies up to date rather than manually tracked what is needed to be changed.

 

This extends to the plugins themselves as well, we will have to accept a "duty of care" to keep them up to date in a timely fashion.

 

Will this make debugging more complicated, yes but whilst we must not end up with an ubuntu-esqe bloated distro we will no longer be able to go weeks, months or years between plugin and dependency updates.

 

This whole thing changes the nature of unRAID, for the better, but we cant cling onto how things used to be done.

 

[yaksaredabomb]

http://lime-technology.com/forum/index.php?topic=28462.msg253499#msg253499

 

Per Tom

There are no longer any "release stopper" issues left.  As soon as I finish the documentation I will release 5.0 "stable".  If I can throw in a few 'cosmetic' type fixes before then I will but primary focus now is finishing docs to aide new users and those moving from 4.7.

 

 

Great work and even better communication lately.  Greatly appreciated by many

 

I'd like to echo graywolf's positive feedback on your work and especially your communication, Tom.  It really has been great to feel more in the loop as to when I might be able to use my 3TB and 4TB drives in a stable release, along with all the many other improvements that are coming in 5.0 (safe mode, etc).  I think the insight into the issues you've been facing and decisions you've been making helps keep the non-computer science people like myself more patient, compared to if we only had the "2011-01-24" 4.7 release date to stare at lol.

 

I'm sure no one needs this mentioned again - but to say it anyways - scope creep is an insidious beast that will find any way possible to "move the target" on a project and cause frustration to all.  Must diligently watch for it and make deliberate decisions about what can be included in 5.0 and what must wait for 5.1.  I think many people are afraid that if this stable release took 2.5+ years to come out, the next one could be years away too - so it may be 2015 before we can use anything that doesn't get squeezed into this release!

 

I have a background in science, where we like to isolate one variable at a time if possible, so my humble opinion is the fewer changes made between releases the better - especially if there are any "big" changes involved as there are in the 5.0 release.  If change lists are kept as small as possible, we won't have to wait till 2015+ for 5.1 "stable" and we won't have to be so concerned about what makes it into the "official" 5.0 release.

 

Best of luck putting on the final touches to the code and documentation, Tom, and thanks again for bringing us "along for the ride" with your updates.

[Ice_Black]

Slackware are headache when it come with dependency package issues.

 

I wish Unraid on Ubuntu or CentOS distribution. Much superior package management.

[bobbintb]

im just going to echo the point i made earlier in regard to this matter:

 

http://lime-technology.com/forum/index.php?topic=28140.msg250742#msg250742

[nicinabox]

This topic is a bit confusing because it attempts to address two separate problems while using the same language for both.

 

Slackware packages are part of the system. These modify the system and are installed from official or 3rd party mirrors.

 

Unraid needs a plugin/addon system to allow configuration of packages or 3rd party services. Package management needs be sorted out before addon management (because of dependencies and version conflicts in packages).

 

Slackware Packages

 

Examples: openssh, libcurl, python, ruby

 

Unlike other distros, Slackware's philosophy is that package management should be the job of the user rather than the system. This really sucks, because it causes all kinds of headache through manual installing. There's no easy way to keep track of version dependencies in packages.

 

Unraid Addons

 

Examples: Plex, Sabnzbd, Transmission

 

I've been brainstorming an addon manager for Boxcar.

 

* Addons use the native package installer (txz) in the background

* Addons specify package dependencies using the pessimistic version constraint (rubygems and npm work this way)

* Addons are registered with an official server. Once registered, anyone can install.

* Addons must include a version number (semver recommended) in boxcar.json

* Addons use a boxcar.json to notify server of a new boxcar addon. This file is metadata for addon.

* Addons can use a DSL to create consistent settings screens for editing

 

[chickensoup]

Hey Tom,

 

I'm sure it's been asked a thousand times but do you plan to include this plugin manager in 5.0 or are you just "testing the water" at this stage? It really feels like it will be more than a minor addition and really should wait until 5.1 or even 5.2. I'd hate to see all of the work that has gone into v5 so far get spoiled by a half baked addition which is very likely to cause more problems than it fixes.

 

Love your work mate but let's kick v5 out the door without the plugin manager and do it right rather than fast.

 

Cheers ;-)

[NAS]

This topic is a bit confusing because it attempts to address two separate problems while using the same language for both.

 

Slackware packages are part of the system. These modify the system and are installed from official or 3rd party mirrors.

 

Unraid needs a plugin/addon system to allow configuration of packages or 3rd party services. Package management needs be sorted out before addon management (because of dependencies and version conflicts in packages).

 

Slackware Packages

 

Examples: openssh, libcurl, python, ruby

 

Unlike other distros, Slackware's philosophy is that package management should be the job of the user rather than the system. This really sucks, because it causes all kinds of headache through manual installing. There's no easy way to keep track of version dependencies in packages.

 

Unraid Addons

 

Examples: Plex, Sabnzbd, Transmission

 

I've been brainstorming an addon manager for Boxcar.

 

* Addons use the native package installer (txz) in the background

* Addons specify package dependencies using the pessimistic version constraint (rubygems and npm work this way)

* Addons are registered with an official server. Once registered, anyone can install.

* Addons must include a version number (semver recommended) in boxcar.json

* Addons use a boxcar.json to notify server of a new boxcar addon. This file is metadata for addon.

* Addons can use a DSL to create consistent settings screens for editing

 

What you are saying here makes a lot of sense to me. The one area that I would worry about is the "Addons are registered with an official server" model. This will work for the core stuff but Toms already said he worrys about "implied endorsment by hosting addons".

 

How viable would it be to allow any number of Addon repositories? Alternatively we will need to come up with some sort of GPL unRAID Addon counsil/peer review system

[dandirk]

How viable would it be to allow any number of Addon repositories? Alternatively we will need to come up with some sort of GPL unRAID Addon counsil/peer review system

 

I would rather see 1 repository for addon's with the ability for the dev to host the content anyway they wish (wget from http or something) if Tom has issue hosting content due to liability or resource cost.  It would be a simple and easy to manage system.  Heck you could even have a link to official DEV thread and do a hash on the file downloaded... It it doesn't match the hash on the DEV post/forum, then don't install.  Hacker would have to hack the forums AND the dev hosted location (or the plugin mgr, which should be separate).  My opinion that would be enough security and simple/flexible enough to handle a lot of situations.

 

XBMC has multiple repository support and it is cool for branched projects like OpenElec, but as a user it just ticks me off for XBMC proper.  I go to the XBMC forum, read all the cool skin/app posts then go home and try and find it...  "wtf its not here... oh must be alpha or not supported on version".  I go check out the forum again and I have to setup some stupid repository for one app/skin.

 

I also think a review system is a bit over the top.  I think it would hinder development more then help it. 

 

Personally I think ensuring the plugin system cannot touch the core server services is a more practical method, prvent plugins from doing damage to the important part... the server.  Worst case scenario for a user that installed a bad plugin is to wipe their flash and re-install unraid...  This also assumes unraid OS can reasonably be wiped and brought back to stock. Like it pretty much is today.

 

As for dep packages... I would say either keep them current (or some agreed to baseline by tom for stability and compatibility) and force devs to keep up or completely isolate addon software + deps so they run any deps they want.

 

 

 

 

 

 

 

[JustinAiken]

Does crossing the 5.0 barrier break 4.7 unMenu plugins? If so, a plugin manager should be top priority - loosing safe power down or Sickbeard is just as bad as a nasty bug for me...

[dandirk]

Does crossing the 5.0 barrier break 4.7 unMenu plugins? If so, a plugin manager should be top priority - loosing safe power down or Sickbeard is just as bad as a nasty bug for me...

 

I would guess you should post that question in the respective plugin threads/forums.  Willing to easily best sickbeard has a 5.0 version (if it isn't already) and you may not require the safe power (don't know what it is sorry).

 

The discussion is just how to manage and deploy plugins vs the manual method most are using now.  Don't think it will/would change plugins to much in the shortterm.