I built my own 3rd Party Synology Package Repository

[DaveR]

I actually created this because you and @Tommes mentioned you wished there was a package repository that was better than cphub and synocommunity, and I didn't want to deal with SynoCommmunity's rules to publish my own packages.

Rather than forcing people to make spk files that conform to what my repository requires or expects, I decided to make it flexible enough to cope with:

1. Missing keys in the INFO file.
2. Whatever naming and versioning format authors have already.
3. It even works if there are no releases and the spk files are in the repo's file tree (complete with inconsistent file names) like https://github.com/BenjV/SYNO-packages.

From my end, to add a new GitHub repo I just add 1 line to my GitHub workflow.

I haven't decided if I want to release the source code yet. I don't want a bunch of copycat package repositories out there while I'm trying to get people to use my package repository.

I just added SynoOCR to the GitHub workflow and your packages highlighted 3 issues with my GitHub workflow, and CloudFlare worker, that I've now fixed. The issues were:

1. GitHub workflow was not finding the PACKAGE_ICON_256.PNG in your spk files.
2. GitHub workflow was trying to create the same packagename_120.png for both DSM6 and DSM7 packages. It now creates packagename_DSM6_120.png for DSM 6 packages and packagename_120.png for DSM 7 packages.
3. CloudFlare worker needed changing to map x86_64 (and all other arches) to the various CPU platforms (all 37 of them).

After 5 hours I finally got synoOCR showing in Package Center for DSM 7 and DSM 6.



Now Medusa has a friend

 

[DaveR]

I didn't realise how many package sources there used to be, and how many are now dead. https://synopackage.com/sources shows 10 working and 27 dead ones.

 

[DaveR]

@geimist
I was checking out the source code for your synoOCR packages to see why they are x86_64 and if they could be noarch, when I noticed they require docker.

In your DMS 7 INFO file you should add: install_dep_packages="ContainerManager"

In your DMS 6 INFO file you should add: install_dep_packages="Dockerr"

 

[geimist]

I haven't decided if I want to release the source code yet. I don't want a bunch of copycat package repositories out there while I'm trying to get people to use my package repository.

That’s a great point! I hadn’t thought of that. I’m all for that idea.

Still, we should make sure to promote your package source. Maybe you could also update your initial post so users can copy the package source URL directly (I didn’t even look for it in the screenshot at first ).

After 5 hours I finally got synoOCR showing in Package Center for DSM 7 and DSM 6.

Oh, I feel sick …
Thank you!

Now Medusa has a friend

Friends are so important

I was checking out the source code for your synoOCR packages to see why they are x86_64 and if they could be noarch, when I noticed they require docker.

Actually, it’s designed for noarch. However, in the last release (1.5.x), I encountered incompatibilities with arm64 involving a Python module that I couldn’t resolve at the time. That’s why the restriction is so strict. But I plan to fix the bug in the next release and then switch back to noarch. Also, I probably won’t be offering any more releases for DSM6. The outcry shouldn’t be deafening (only 1.2% of update requests still come from DSM6).

In your DMS 7 INFO file you should add: install_dep_packages="ContainerManager"
In your DMS 6 INFO file you should add: install_dep_packages="Dockerr"

Yes, that would be consistent. However, in the past there were devices for which there was no Synology installation of Docker (not even using workarounds). That’s why I manually check for Docker in preinst. But I think I might reconsider this approach now.

EDIT: I'm just wondering if it's really that simple. The switch from the Docker package to Container Manager wasn't from DSM 6 to DSM 7, but from DSM 7.1 to DSM 7.2. From the update requests, I can see that over 160 users are still using DSM 7.1. This will likely be addressed in a future update.

 

[DaveR]

Homebridge have joined the party! I asked if I could add their packages and they said yes.

 

[geimist]

Good morning, Dave

During my tests, I found that Ookla Speedtest cannot be installed: "Invalid file format"
(on my DS920+ and on the Synology demo server).



I don't need it, but I just wanted to let you know.

 

[DaveR]

@geimist
I forgot that Container Manager is only DSM 7.2 and later. So you'd need DSM 7 and DSM 7.2 spk files.

In your DMS 7.2 INFO file you would need:

install_dep_packages="ContainerManager"
firmware="7.2-64570"
os_min_ver="7.2-64570"
os_max_ver="9.9-99999"

In your DMS 7 INFO file you should add or edit:

install_dep_packages="Docker"
firmware="7.0-40000"
os_min_ver="7.0-40000"
os_max_ver="7.1-99999"

 

[DaveR]

During my tests, I found that Ookla Speedtest cannot be installed: "Invalid file format"

I'm not sure what is going on there.

I can upgrade it or install on my DS1821+ (v1000 CPU) and DS925+ (v1000nk CPU) but not on my DS720+ (geminilake CPU). Sometimes when I try to install Ookla on the DS720+ it just refreshes Package Center and does not even try to download the spk file. Other times it downloads the spk file and shows the "Invalid format" error.

EDIT:

1. Upgrading on all 3 NAS works.
2. Installing on all 3 NAS fails.

 

[geimist]

I've now tried installing the packages manually (OoklaSpeedtest-x86_64-v1.0.27-DSM-7.x.spk, OoklaSpeedtest-noarch-v1.0.27-DSM-7.x.spk).
All devices are displaying the same error (DS218+, DS220+, DS920+, DS224+)

So it's clearly not a problem with the package server.

 

[Benie]

During my tests, I found that Ookla Speedtest cannot be installed: "Invalid file format"
(on my DS920+ and on the Synology demo server).

It´s me to, about that, so I tried 10 Minits ago, got same Error is Displayed on my DS1525+,

Edit: I could install on my DS920+ at the Time you made the 1.st .spk wenn you start with Ookla Speedtest as an .spk, and it was still working.

 

[DaveR]

I've found and fixed the problem. In v1.0.27 I'd added a 2nd ui page in the WIZARD_UI/install_uifile but I'd left out the },{ between the "Permission setup required" section and the "How to schedule Ookla Speedtest" section. So install was failing but upgrade and uninstall were working.

All fixed now in v1.0.28.

 

[geimist]

@DaveR
How does the package server handle beta versions? Has this been implemented?
Possible indicators would be prerelease versions from GitHub or the information in the package's INFO file.