Any plan to support DSM 7.x beta ?

[vletroye]

Do you have any plan to list also packages dedicate for that new version of the DSM ?

[szyb]

Yes, issue #154.
I was thinking it would be easy task, but version 7.0 breaks our cache mechanism.
Moreover many servers are not ready for this version yet and they will serve packages that are not compatible with 7.0.
I'm planning to test this version as VirtualDSM

[vletroye]

many servers are not ready for this version yet and they will serve packages that are not compatible

As per Synology documentation, a package is only valid for DSM 7.x if the min version of firmware, defined in INFO file, is 7.0-40000. So, the Package Manager of a DSM 7.x will never show any package with a lower version... And the package manager of a DSM 6 x won't show any package with a minimum firmware >= 7.0

So, I am not sure to understand this remark?!

Regarding the caching issue... the easiest could be to duplicate your website: a new one for packages with a target firmware >= 7.0 and the current one for the other versions. Each one having its own cache, updated only with packages having the right target firmware version :D

But I guess that you actually expect your website to filter the supported packages based on the dsm version picked in the upper right combo, next to the Synology model?!

[szyb]

It should be like that, when package version is < 7.0 then is should not be even visible in DSM 7.0. But my very first tests with DSM 7 shows that all packages from the sever are visible in DSM 7, but when I try to install it there is an compatibility error. This might be only "Beta" issue, so the user may request the publisher to provide newer version of the package. This might be done on purpose in Beta, because it is better for user to claim new version than realize that there is no package you are looking for.

Regarding to caching, it works in that order:

1. If there is a cached file for exact DSM version and exact model and it is not older that 24h then we show the cached result to the user
2. If the request to the source server succeed we present the data directly from the server (and save the response in cache)
   [EDIT - Previously I was wrong so I changed the algorithm below and kept only valid description]
3. If previous request failed then we get the newer cache from:

• exact DSM version & exact model
• exact DSM version & same architecture as requested model

So each time we try get data from cache we do it for exact DSM version as provided by user. In conclusion this could be not as big issue as I thought. I will test and analyze it more.

[szyb]

I edited previous post, so it contain only valid description of the caching algorithm

[szyb]

I've been playing around with DSM 7 together with some source repositories and:

1. Many servers provides packages that doesn't work on DSM 7, but there are some that works (i.e. from synocommunity, but as I can see the work is still in progress out there)
2. The Package Center in DSM7 shows every package returned by the repository, but the installation fails if it is not compatible. The minimum version for the package is contained in SPK not in the JSON response (with the package list).
3. For the same reason mentioned above we cannot filter out packages with minimum version < 7

And finally: support for DSM 7 can be easily add to synopackage, by just adding the version to the config file. PR is ready. Caching is not a problem.