Support os_max_ver

[hgy59]

In October 2025 Synology released DSM 7.3 that does not support PHP < 8.2 anymore.

All packages that do not support PHP 8.2 (i.e. support PHP 7.4 or PHP 8.0 only), must used the os_max_ver attribute in the INFO file to declare a package incompatible with DSM 7.3+.

But such packages must not only declare something like os_max_ver="7.2-81000" but also the spkrepo API must ensure that those are not delivered to DSM 7.3 models.

We already can define OS_MAX_VER = 7.2-81000 in the SPK Makefile to add os_max_ver to the INFO file in the spk, and the package center will avoid the installation with a related error message (i.e. for manual installation).

BUT spksrc (the repository) must evaluate the os_max_ver too, so that packages do not appear in the package center of incompatible DSM version.

So far spkrepo has only os_min_ver implemented - the foreign key firmware_id links to the firmware table with dedicated firmware versions (according to available toolchains).
For os_max_ver this approach is n/a because there are no dedicated max build revisions. We could either define 7.2-99999, 7.2-80000, 7.2-81000, or 7.2-81180 for packages not supported on DSM 7.3+ (I propose an additional column for os_max_ver in the build model).

It would be handy, when os_max_ver could be set in the admin UI, because it must be defined for already published revisions of a package not supported on DSM 7.3+.

[mreid-tt]

Thanks for raising this. There’s a major Flask-Admin update coming soon, which will be a good opportunity for me to get back into some development work on the platform. I plan to include the os_max_ver logic you mentioned, with a few refinements.

Regarding the specific issue with the PHP packages — wouldn’t users be unable to install them anyway, since the prerequisite of PHP < 8.2 wouldn’t be met?

EDIT: Regarding setting os_max_ver in the UI — that would be somewhat irregular, since this information is usually read from the INFO file. Allowing it to be set manually could create situations where the database becomes out of sync with the package. Thoughts?

[hgy59]

Regarding the specific issue with the PHP packages — wouldn’t users be unable to install them anyway, since the prerequisite of PHP < 8.2 wouldn’t be met?

Yes, this is the main reason of this issue. Packages that can't be installed should not be delivered by the respository, i.e. must not appear in the DSM package center.

[hgy59]

Allowing it to be set manually could create situations where the database becomes out of sync with the package. Thoughts?

This is for editing packages that are published before we add the os_max_ver to the database..
It is only to prevent delivery to the DSM package center (it does not prevent manual download, that will fail to install).
I guess you agree that we don't want to fix this issue by removing all incompatible packages...

So we will only need one update per unsupported package with the os_max_ver and set the same os_max_ver manually in earlier published packages.

[mreid-tt]

This is for editing packages that are published before we add the os_max_ver to the database.. It is only to prevent delivery to the DSM package center (it does not prevent manual download, that will fail to install). I guess you agree that we don't want to fix this issue by removing all incompatible packages...

I wouldn't say we don't want to remove incompatible packages but I think the solution should not be to manually edit database entries. A simple method can be to publish new versions of apps which include the os_max_ver attribute and then disable the older versions in the repo so they won't show in the DSM Package Center.

[mreid-tt]

Hey @hgy59, I believe we need to reconsider this. I did some additional testing with Adminer after your #159 (comment). I downloaded all four files from your build and attempted to upload. The one for DSM 7.2 did not upload because there was an overlapping firmware range with the one for DSM 7.0.

The reason for this is based on this code:

else ifeq ($(call version_ge, ${TCVERSION}, 7.0),1)
SPK_DEPENDS = "WebStation:PHP8.0:Apache2.4"
# DSM >= 7.3 does not support PHP8.0
OS_MAX_VER = 7.2-81180
# DSM 7.0 and 7.1
CONF_DIR = src/conf_dsm7

We are using the os_max_ver as the top of the boundary, excluding that build. This is not how the DSM developer guide defines it:

Field Name: os_max_ver

• Description: Maximum version of DSM that is capable to run the package.

In short this means that we cannot include DSM 7.2 as it would indicate that the build is capable of running on DSM 7.2 which is not the intent. To align with this definition you would need to set the os_max_ver to be DSM 7.1 build 42962 which is the highest version currently available. Then the repo would look like this:

This of course is not sustainable since Synology could release a later version of DSM 7.1 which would be beyond this build configuration value.

Looking back at how Synology constructs their package, they only seem to include os_min_ver as follows:

Package	os_min_ver
PHP7.3	7.0-41300
PHP7.4	7.0-41300
PHP8.0	7.0-41300
PHP8.1	7.2-60096
PHP8.2	7.2-60096

On older DSM 6, it looks like this:

Package	firmware
PHP7.3	6.2-22232
PHP7.4	6.2-22232

I propose that in light of this we don't set the os_max_ver value and just leave the catalog to select the highest compatible version. What this means is that if a version 7.0 and a version 7.2 exists it will pick the version 7.2 as we do with Lidarr and Prowlarr.

On further testing however, this does not always work because of the way we have the mk/spksrc.tc-vers.mk file setup. There are some build numbers which don't represent the start of the DSM version line and as such, we are excluding earlier DSM versions within that same line. Extracting the contents we have this (along with recommended corrections):

DSM Ver	Build Num	Suggested Build
1.1 (SRM)	6931	6338
1.2 (SRM)	7742	-
1.3 (SRM)	9193	-
4.0	2198	2197
4.1	2636	-
4.2	3202	-
4.3	3776	-
5.0	4458	-
5.1	5004	-
5.2	5644	5565
6.0	7321	-
6.0.2	8451	-
6.1	15047	15022
6.2	22259	23739
6.2.2	24922	-
6.2.3	25423	-
6.2.4	25556	-
7.0	41890	-
7.1	42661	-
7.2	72806	64561

The suggested builds were taken from the release notes of the earliest version in that line. The one for DSM 7.2 is the most out of alignment as that is actually 7.2.2-72806 Update 4 which excludes many earlier DSM 7.2 versions. It should be the one proposed or the earliest publicly available version from the release notes which is 7.2-64561.

[hgy59]

Related to build number:

I don't think we need to change anything related to suggested builds.
We only have DSM toolchains for 5.2, 6.2.4, 7.0, 7.1 and 7.2 and we don't build for DSM 7.0
We can ignore all others.
The build number is taken from the toolchain we use.
All suggested numbers are lower than the number we use, so there is no problem (like feature not supported with build number xy).
IMHO it is not worth to use the lowest possible build number.

Related to os_max_ver
There is indeed an overlapping of supported DSM versions.
Adminer noarch-7.0 is supported on DSM 7.0, 7.1 and 7.2
Adminer noarch-7.2 is supported on DSM 7.2 and 7.3

If we can't support overlapping versions in the repository we must omit the os_max_ver in this case.
But if we wouldn't provide Adminer noarch-7.2 the noarch-7.0 package must define os_max_ver to hide the package on DSM 7.3.
So it depends.
But I would prefere a solution that supports such overlapping versions...

[mreid-tt]

Related to build number:

I don't think we need to change anything related to suggested builds. We only have DSM toolchains for 5.2, 6.2.4, 7.0, 7.1 and 7.2 and we don't build for DSM 7.0 We can ignore all others. The build number is taken from the toolchain we use. All suggested numbers are lower than the number we use, so there is no problem (like feature not supported with build number xy). IMHO it is not worth to use the lowest possible build number.

I do think we need to change at least the DSM 7.2 build number though. At 7.2.2-72806 Update 4, someone could reasonably have DSM 7.2.2-72803 because they hadn't yet manually updated to 7.2.2-72806 (since they won't receive notifications for this update according to the release notes). In this circumstance, running a Lidarr or Prowlarr update would give them the version for DSM 7.1. As noted in these PRs those versions disable auto-update and would provide a very different experience than what was intended.

Related to os_max_ver There is indeed an overlapping of supported DSM versions. Adminer noarch-7.0 is supported on DSM 7.0, 7.1 and 7.2 Adminer noarch-7.2 is supported on DSM 7.2 and 7.3

If we can't support overlapping versions in the repository we must omit the os_max_ver in this case. But if we wouldn't provide Adminer noarch-7.2 the noarch-7.0 package must define os_max_ver to hide the package on DSM 7.3. So it depends. But I would prefere a solution that supports such overlapping versions...

I wouldn't want to have overlapping supported builds for the same version as this would cause us to stray from the developer guide and likely what the Package Center expects from repository servers.

EDIT: Alternately, I could update the code to dynamically present the highest version below the one specified in os_max_ver when the catalog is built. That way it could be future proofed as we add additional firmware versions to the repo. In that case, I would prefer we call the variable something other than os_max_ver since that behaviour would be different than the definition in the developer guide.

[hgy59]

The other cause is, that we only support major.minor versions in the repository.
So we can't distinguish the 7.2.* versions

build number 72806 is DSM 7.2.2, 69057 is DSM 7.2.1 and 64570 is DSM 7.2.

To avoid DSM 7.1 packages on DSM 7.2 or 7.2.1 you need to define os_max_ver in the Prowlarr and Lidarr packages you mentioned.

[mreid-tt]

We were discussing moving away from using os_max_ver. Is there a reason you are against changing the TC_VERS for 7.2 to 64561? Would something break if we did this?

EDIT: The main challenge I am flagging is that if we don't use overlapping firmware ranges (I don't think we should) and we use os_max_ver, there will generally be a gap between the end of the range and the start of the next range for which users may be either presented with a less than ideal build or no build at all. As such, the start of the range should be set by us and not just match the firmware of the toolchain.

To avoid DSM 7.1 packages on DSM 7.2 or 7.2.1 you need to define os_max_ver in the Prowlarr and Lidarr packages you mentioned.

EDIT: If I did that then DSM build versions between 42962 and 72806 would likely have no package served to them.

[hgy59]

We were discussing moving away from using os_max_ver.

but we need os_max_ver for packages not supported on DSM 7.3 (like owncloud).

[mreid-tt]

We were discussing moving away from using os_max_ver.

but we need os_max_ver for packages not supported on DSM 7.3 (like owncloud).

Fair. In that use-case we should use a synthetic number as the value. So if the first value recognised by Synology for DSM 7.3 is 7.3-81180, then we could pick a number like 7.2-79999 as the last expected version for DSM 7.2. This should be reasonable as the current latest in the 7.2 line is 7.2.2-72806 Update 4.

EDIT: In a similar way we can pick a synthetic number like 7.1-59999 as the last expected version for DSM 7.1 since the current latest in the 7.1 line is 7.1.1-42962 Update 9.

This does not negate the need to change the TC_VERS for 7.2 to 64561.

EDIT: Alternately we can use an older toolchain like 7.2-63134 which would be more inclusive of older DSM versions in the 7.2 line.

[mreid-tt]

Speaking of toolchain 7.2-63134, I was looking at Adminer again and the build in the repo does use the older toolchain:

This however is confusing to me since the newer toolchain was installed since Jun 13 (via SynoCommunity/spksrc#6606) so I'm not sure how it was built using this older version. Looking at the build I did two weeks later, it uses the updated toolchain:

Can you shed some light on this for me? Because if I had a choice I would much rather build for 7.2-63134 to be more inclusive.

EDIT: I think it's probably because it's a noarch package that uses the older 7.2 toolchain just like how it uses the older 7.0 toolchain.