Bug#873411: kdevelop: Please update to llvm-toolchain 4.0 or, better, 5.0
Hi Pino,
On 20/11/17 20:27, Pino Toscano wrote:
> Control: severity -1 important
>
> (see below why...)
>
> In data lunedì 20 novembre 2017 20:05:20 CET, Emilio Pozuelo Monfort ha scritto:
>> Control: severity -1 serious
>>
>> On Wed, 06 Sep 2017 21:34:47 +0200 Pino Toscano <pino@debian.org> wrote:
>>> Hi,
>>>
>>> In data domenica 27 agosto 2017 16:01:25 CEST, Sylvestre Ledru ha scritto:
>>>> Source: kdevelop
>>>> Severity: normal
>>>>
>>>> Hello,
>>>>
>>>> Currently, we have 6 versions of the llvm toolchain in the archive.
>>>> I would like to move to 3 versions (4.0, 5.0 and snapshot, aka 6.0)
>>>>
>>>> Could you please update your package to use 4.0 (or, better, 5.0 which will be released very
>>>> soon)?
>>>
>>> Sure, but only after the versions available build and work at least on
>>> all the release architectures. So far, llvm 3.9 is still affected by
>>> #866354, since it did not build fine again since then -- this is
>>> holding kdevelop in unstable for more than 2 months, and I really would
>>> like to get it into testing.
>>>
>>> I see that each of the llvm sources has various bugs, FTBFSes, cmake
>>> issues, and so forth... as a suggestion from a bystander, what about
>>> focusing on at most 3 versions of llvm in the archive, instead of
>>> upload every version available (and then have to cleanup llvm users
>>> periodically, like with bugs like this)?
>>>
>>>> I will update the severity of this bug at the end of September
>>>
>>> Doing that with the current state of llvm versions would be a bad idea.
>>
>> It should be fine now with 4.0. Would be good if this could move to either
>> unversioned llvm/clang (which defaults to 4.0 now) or to versioned 4.0. Bumping
>> to serious as we want to remove 3.8 soon to reduce the high number of llvm
>> versions that we currently ship.
>
> IMHO, if the goal would really be getting rid of old llvm versions in
> the archive, then (as I wrote above) the llvm maintainers ought to
> a) fix the latest stable (= 5.0)
> b) switch llvm-defaults to the above
I expect that will happen in due time. I see there's a 5.0.1 rc release in
experimental already, which is in a much better shape than the package in
unstable. Hopefully when 5.0.1 final is released it can go in unstable and the
remaining issues can be worked out.
In the meantime, that shouldn't block kdevelop from going back to unversioned
llvm, which defaults to 4.0 now, and when it gets bumped to 5.0, a binNMU will
be scheduled and you won't have to worry about it.
FWIW wrt your old comments: I would have no objections to uploading only every
other major release to Debian, but I am not an LLVM maintainer, and so long as
older releases get cleaned up and transitions are taken care of, I won't object.
We were due a llvm-defaults update, which just happened. Hopefully the process
is better understood now and an update for 5.0 or 6.0 won't take too long. Also
hopefully more packages go back to using the metapackages, so that we can just
scheduled binNMUs when the defaults are updated and be done with it. OTOH there
are very few rdeps so this is not a huge deal.
> llvm got versioned symbols, so loading two llvm versions in the same
> process (hello, mesa), although it is ugly. This should allow kdevelop
> to switch back to llvm-defaults, even if llvm maintainers should care
> a bit more about it, instead of almost letting it rot...
So you are saying that you can use llvm 4.0 even if mesa is using 5.0? That's good.
> Anyway, I just lowered the severity of this bug to important, so
> kdevelop 5.2 can migrate to testing. Yes, it is an important update
> (merged kdevplatform, so the separate source can be dropped), so I
> really it to reach testing.
> Because of another issue in the past, related to llvm (#866354),
> kdevelop 5.1.x was stuck in unstable for basically 2 months. I don't
> want llvm to get in the way of kdevelop, once again.
I don't want that at all, so that's alright. I don't think this bug being
serious would have prevented kdevelop from migrating to testing anyway, as it's
not a 'regression'. In any case, I just noticed you're on llvm 3.9 and not 3.8,
and we can't remove 3.9 yet due to GHC (sigh), so this is less urgent. It'd
still be nice for this to move to unversioned llvm or to a newer one whenever
possible.
Hopefully that makes sense. Let me know if that's not the case.
Cheers,
Emilio
Reply to: