(do not) Upgrade package for specific arch/dsm

[vkostas]

I had noticed the very nice innovated idea of toolchain subversions (syno-avoton-5.0, syno-avoton-5.1, syno-avoton-5.2). :+1: Is it planned something similar for package Makefiles? A package can be (in)compatile with a DSM (all archs) or specific arch (all DSM) or combination of them.

Say someone wants to upgrade to boost from 1.53 (5.0) to 1.59 (5.1) and later another one wants to upgrade to Boost 1.60 (5.2).

Boost version	Current DSM	Supported toolchains	Compatible with
1.53	5.0	syno-*-3.1 - syno-xxx-5.0	All toolchains
1.59	5.1	syno-*-5.1	Last DSM only (all archs)
1.60	5.2	syno-*-5.2, except syno-qoriq-5.2	Last DSM only (partly)

If we achieve to have multiple Package Makefiles (supported archs probably must be declared of course) then the package upgrade would be easy since it will be always backward compatible. Less hassle (keep old dsm/archs to previous package version). We won't introduce additional _non supported archs _.

This way a package was compatible with a toolchain will remain as such since it cannot be further upgraded. The contributor willing to upgrade a package must ensure the new PR will be compiled for the same toolchains used to work before his PR.

Thanks!!!

[Diaoul]

This is a lot of overhead and I don't think anyone has the resource to properly maintain hard libraries such as this one. The idea is to support latest official stable version and the previous major release as best effort. If one wants an old librarie, one can just rewind commit history to a point where the old DSM version was supported and build up on that.

If you can come up with a nice implementation for that issue I'll gladly accept it but it has to be easy to maintain.

[vkostas]

@Diaoul I think I have a good solution (short enough not complex at all) :-)

In Makefile we only need to define the new variable MAKE_PREVIOUS_VERSION (or whatever you think is better). if ...........---> use $(ARCH) and/or '$(TC_VERSION) to activate previous version MAKE_PREVIOUS_VERSION = cross/<package_old_version> endif

Deactivate compiling actions for current Makefile in ./mk/spksrc.cross-cc.mk (just before statement include ../../mk/spksrc.cross-env.mk)

# Compile previous version ifneq ($(MAKE_PREVIOUS_VERSION),) DEPENDS = $(MAKE_PREVIOUS_VERSION) # Disable Checksum PRE_CHECKSUM_TARGET = none CHECKSUM_TARGET = none # Disable Download PRE_DOWNLOAD_TARGET = none DOWNLOAD_TARGET = none # Disable Extract PRE_EXTRACT_TARGET = none EXTRACT_TARGET = none # Disable Patch PRE_PATCH_TARGET = none PATCH_TARGET = none # Disable Configure PRE_CONFIGURE_TARGET = none CONFIGURE_TARGET = none # Disable Compile PRE_COMPILE_TARGET = none COMPILE_TARGET = none endif

[Diaoul]

The problem with that if I understand correctly is that the same package could result in various versions of dependencies and thus not be consistent.

[vkostas]

@Diaoul hmm, Good point... I was thinking to solve the issue a particular subpackage (say it FLAC) must use an older version for specific arch and/or dsm even we produce a new PKG (say it mpd) because all the rest of subpackages have been upgraded. A main package referring to this subpackage directly would be rather easy to be solved (create a sibling main cross/package) but if it refers indirectly then the puzzle becomes much more complex (create a sibling subpackage at each level). e.g. (not real) Direct link mpd (qoriq) --> FLAC 1.2.1 mpd (else) --> FLAC 1.3.1

Indirect link mpd (qoriq) --> libsndfile (qoriq) --> FLAC 1.2.1 mpd (else) --> libsndfile (else) --> FLAC 1.3.1

The dependency can go even at lower level. My goal is not to mix various versions to the same pkg but to (easily???) integrate parallel versions of same (sub)package. I admit my logic lacks at one the point: the subpackage (FLAC) does not "know" whether upper one indeed wants to build the older (compatible) version or not. This is something to think off.

Maybe it can be solved by introducing a "flag" use-legacy-packages... Even we have "split" flac in two versions, the legacy version would be build only if "flag" build-legacy-version is set. I have to think how this can be technically implemented. A new optional argument after toolchain --> make arch-dsm-version <use-legacy-packages> maybe?. Makefile would check if flag is set and only then continue to build compatible version.

To finalise.

1. Build mpd (qoriq): make arch-qoriq use-legacy-packages (all but qoriq fail)
2. Build mpd (non-qoriq) make arch-avoton (qoriq fails).

That means build a separate PKG for each combination. This way we can continue maintain some specific arch do not support all latest cross/packages.

[Diaoul]

This is dependency hell, don't go there. We either update the dependencies if all latest arches can compile it or we don't. There is no point in having the latest boost library, I never heard anyone complaining about that. As long as the spk works that's all that matters in the end. There is no other cross compilation framework that solve this issue, take a look at openembedded and optware. Our best shot is to report to Synology and have better toolchains.

[vkostas]

oke. oke. I don't need it for any of my project (boost, mpd, flac were just fictional examples). :-) It was just a thought I had.