Hi Peter and All,
On Tue, 2017-11-14 at 23:32 +0000, peter green wrote:
> 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.
Yes, I think this is the way to go in order to avoid the need of re-uploading
binary packages in cas anything goes wrong.
> 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.
In fact, the biggest interest of MA for FPC is to build for arm and especially
to cross build for Android. So I fear that this is not a tiny goal. Otherwise we
drop MA support which will be a pity.
> 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.
This is indeed the mail problem. People are asking for better MA support to be
able to use FPC for their phone development and here arm architectures are
important.
Upstream solves this by using a different base dir. We can for instance replace
/usr/lib/${DEB_PACKAGE_NAME}/${DEB_UPSTREAM_MAIN_VERSION}by/usr/lib/${FPCTARGET}-${FPCARCH}/${DEB_PACKAGE_NAME}/${DEB_UPSTREAM_MAIN_VERSION}This
is probably less intrusive, but have 2 levels of ${FPCTARGET}--
Cheers,
Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
