On 14/11/17 22:21, Abou Al Montacir wrote:
Hi Paul, and All,I've just pushed a commit [1] that I hope will improve the situation of MA support. In this commit I've moved units from ${LIB_DIR}/units/${FPCTARGET}-${FPCARCH} to ${LIB_DIR}/units/${FPCTARGET}-${FPCARCH}/'$${PACKAGE_NAME}' where LIB_DIR=/usr/lib/${DEB_PACKAGE_NAME}/${DEB_UPSTREAM_MAIN_VERSION} FPCTARGET=$(CPU_TARGET)-$(OS_TARGET) FPCARCH=$(shell dpkg-architecture -qDEB_BUILD_ARCH_ABI) This makes each architecture installs its units in a separate directory. I've also added a patch against fpcmkcfg to change /etc/fpc.cfg to look for the units in the right place depending on the cpu/os tragets and the used ARCH/ABI. I did not upload this as I did not test it extensively and I fear this is a quite big change that may require manual upload for many arches is not tested extensively before it is uploaded. I'd prefer to have it in experimental first also in order to avoid annoyance to our users. Please let me know what do you think about it. [1]: https://anonscm.debian.org/cgit/pkg-pascal/fpc.git/commit/?id=a5bfc6ba0fa81 c9e1d627d9314078cb1ddb3d329
Going to experimental before unstable with aggressive changes certainly makes sense. IIRC experimental buildds only use build-depends from experimental when required to satisfy version constraints, so by changing version constraints one can choose whether to build a new version in experimental with the previous version from experimental or with the known-good version from unstable. However I am skeptical as to whether such an aggressive change is really needed. IMO given the relatively small scale of this problem it makes more sense to leave most architectures alone and only deviate from upstream where we actually need to do so. I just ran a quick check and currently the only architectures with a conflict are armel and armhf. It seems likely ppc64el would also have a conflict but IMO we can cross that bridge when we come to it.
