[Pkg-gambas-devel] Bug#803647: Bug#803647: Bug#803647: No solution for llvm and gambas (for now)

[Gianfranco Costamagna]

Hi, 


>Only while llvm-3.5 stays in sid, and even for that case it's not a good policy. We can do it for the good of the users for sometime. Maybe gambas developer will >update the library in the meantime. If you agree I can do it, if not the only solution is disabling llvm component from being built in the packaging.

>> so, since we don't know how to patch, and the component is optional I
>> think I'll leave the current status quo, and maybe disable llvm on
>> gambas if you eventually want to remove it from Debian.
>generally when a project radically changes its API, the old version is
>maintained for
>some time (often years, think python 2.x and the old Linux kernels)
>llvm-3.5 is still an available package in stretch and jessie, wouldn't
>it be possible to have a specific dependency on llvm-3.5, until
>upstream point gb.jit to 3.6?
>


this is *exactly* what I did, force the 3.5 dependency in control file and rules file.
llvm-3.5-dev [!hurd-any],

and 

./configure --host=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) --build=$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) LLVM_CONFIG=/usr/bin/llvm-config-3.5

the problem actually is that we removed llvm-3.4 only recently because ghc on arm* was needing it.

The new ghc 7.10 requires llvm-3.5, but AFAIR it is specially embedded in ghc source code.

So the only two reverse-dependency left seems to be gambas3 and pocl.
I'm not sure how long llvm people will continue shipping llvm-3.5 (together with 3.6, 3.7, 3.8 and snapshot) because of two reverse dependencies.

I did recently a lot of work in pkg-llvm team (not that lot, but a few uploads) and I can say that maintaining 5 different llvm versions means
5 times the work in patching-rebasing, keeping up to date with CVEs.

So, this is what I said before, I kept the llvm binding enabled, but I can't promise the llvm Debian maintainer will keep it for Stretch, so
the intent of the mail was: "be prepared, the component (optional) might disappear soon".

And upstream seems to put little effort in updating it (AFAIK the man who did the work is not available anymore, so there is almost nobody
that has knowledge to work on it).

cheers,

Gianfranco