You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Synology's routers are about just as good as their NAS systems - including support for software installed through packages. However the package situation at the moment is quite... Barren. Synology itself offers only a handful of packages, almost none of them are interesting for the average user, however they also fail at providing instructions, or documentation on the topic (not to mention there's not even a "custom sources" option in the package manager - hopefully with DSM 7.0, SRM 2.0 will also be released, and hopefully that will bring some of the features from DSM to SRM).
However, Synology did make their whole toolkit available on Sourceforge. Unfortunately it's not in a format the current EnvDeploy script recognises. I've made a quick and dirty to-do list on what needs to be done to add SRM support:
Make Product variable
Currently, the Product bit in EnvDeploy is set statically to DSM. Changing this to a dynamically resolved type variable (either DSM or SRM) via a --product argument would be desirable (otherwise mixups between DSM and SRM toolkits will happen).
Add SRM platforms to the toolkit info file
SRM has three platforms available at the moment: northstarplus (RT1900ac), ipq806x (RT2600ac) and dakota (IPQ4019 based MR2200ac)
Versions: 1.1 and 1.2 for northstarplus and ipq806x, 1.2 for dakota
Update EnvSetup for SRM environment
As far as I can see, SRM has no base file for the dev environment. I'm not sure how much of an impact this will be - based on what I can see in the 6.2 base tar, it should work, but I suppose further testing is required. SRM packages are also structured slightly differently, following the old style of Synology for SourceForge uploads: instead of being {Product}{DSM.Version}/{platform}/ on top of the SourceForge toolkit URL, it is simply {platform}/. Package naming (ds.{platform}_{DSM.version}.{env/dev}.txz) is the same as the DSM files, though.
The text was updated successfully, but these errors were encountered:
Synology's routers are about just as good as their NAS systems - including support for software installed through packages. However the package situation at the moment is quite... Barren. Synology itself offers only a handful of packages, almost none of them are interesting for the average user, however they also fail at providing instructions, or documentation on the topic (not to mention there's not even a "custom sources" option in the package manager - hopefully with DSM 7.0, SRM 2.0 will also be released, and hopefully that will bring some of the features from DSM to SRM).
However, Synology did make their whole toolkit available on Sourceforge. Unfortunately it's not in a format the current EnvDeploy script recognises. I've made a quick and dirty to-do list on what needs to be done to add SRM support:
Product
variableCurrently, the
Product
bit in EnvDeploy is set statically to DSM. Changing this to a dynamically resolved type variable (either DSM or SRM) via a--product
argument would be desirable (otherwise mixups between DSM and SRM toolkits will happen).SRM has three platforms available at the moment:
northstarplus
(RT1900ac),ipq806x
(RT2600ac) anddakota
(IPQ4019 based MR2200ac)Versions: 1.1 and 1.2 for
northstarplus
andipq806x
, 1.2 fordakota
As far as I can see, SRM has no
base
file for the dev environment. I'm not sure how much of an impact this will be - based on what I can see in the 6.2 base tar, it should work, but I suppose further testing is required. SRM packages are also structured slightly differently, following the old style of Synology for SourceForge uploads: instead of being{Product}{DSM.Version}/{platform}/
on top of the SourceForge toolkit URL, it is simply{platform}/
. Package naming (ds.{platform}_{DSM.version}.{env/dev}.txz
) is the same as the DSM files, though.The text was updated successfully, but these errors were encountered: