clone 887575 -1 assign -1 src:fpc retitle -1 fpc MA setup breaks some reverse dependency builds found -1 3.0.4+dfsg-13 block 887575 by -1 thanks
Hi On 18-01-18 14:44, Abou Al Montacir wrote: > On Thu, 2018-01-18 at 06:43 +0100, Michalis Kamburelis wrote: >> The problem is caused by the different directories used by new FPC >> 3.0.4 packages (compared to previous versions of FPC in Debian). > I must admit that I was expecting many packages to break as the change > is too big. > But I assume this is worth the pain as now we can install multiple > architecture units on the same host. But I think this must be fixed in fpc (therefore the clone of the bug), not in all the packages that build using it. >> Doing >> >> ./fpmake --globalunitdir="/usr/lib/fpc/3.0.4" > Why do we need this? FPC should use the /etc/fpc.cfg to get this, why do > we need to explicitly pass this? >> doesn't work, since /usr/lib/fpc/3.0.4 does not exist. This works: >> >> ./fpmake --globalunitdir="/usr/lib/x86_64-linux-gnu/fpc/3.0.4" > I would use > > DEB_HOST_MULTIARCH=$(dpkg-architecture -qDEB_HOST_MULTIARCH) So, /etc/fpc.cfg should be fixed, no? Can that be done in a MA manner? If not, I consider the whole fpc/MA design broken. >> To fix this, I suggest to >> >> - Change / define the $FPCDIR variable inside Debian build scripts, to >> point to the new correct directory. > I would try to avoid this if possible but indeed seems correct solution I disagree. I think a solution where every package needs to define this is wrong. >> - Or create a symlink /usr/lib/fpc/3.0.4 -> >> /usr/lib/x86_64-linux-gnu/fpc/3.0.4 . > This brings us back to pre-MA epoch. Let's avoid it. Also not possible > in the Debian auto-builder daemon. The first sentence is what I also thought, but what do you mean by the last? Paul
signature.asc
Description: OpenPGP digital signature
