[PATCH] Re: KDE 4.6.0: go or no go?

[Ian Monroe]

On Thu, Jan 20, 2011 at 14:05, Alexander Neundorf <neundorf at kde.org> wrote:
> On Thursday 20 January 2011, Ian Monroe wrote:
>> On Thu, Jan 20, 2011 at 12:20, Alexander Neundorf <neundorf at kde.org> wrote:
>> > On Thursday 20 January 2011, Dirk Mueller wrote:
>> >> On Wednesday 19 January 2011, Dirk Mueller wrote:
>> >> > so the general consensus seems to be against slipping the schedule and
>> >> > inserting a RC3.
>> >> >
>> >> > This means that we need to solve bug 246678. Given that there seems to
>> >> > be no fix in sight (no comment in the last 14 days), can we mitigate
>> >> > it. is there a way to disable whatever causes the problem by default?
>> >> > what would be the patch for that?
>> >>
>> >> Hi,
>> >>
>> >> I think the attached patch should make the services be disabled by
>> >> default, thereby avoiding kde bug 246678. I'm asking for a review and a
>> >> comment whether we can go ahead with this workaround for KDE 4.6.0.
>> >>
>> >> As the general consensus was (previously) already against slipping the
>> >> schedule, I need a solution NOW to be able to release 4.6.0 in time.
>> >
>> > Did you try building KDE 4.6.0 with CMake 2.8.4rc1 ?
>> >
>> > If not, please do so.
>> >
>> > There has been a relatively significant change in it wrt to how include()
>> > and find_package() find their files (now when a file which is part of
>> > cmake calls include() or find_package() it first looks in
>> > CMAKE_ROOT/share/cmake/Modules/ instead of first looking in
>> > CMAKE_MODULE_PATH).
>> >
>> > I didn't have a lot of time since mid of December, so I didn't get around
>> > to give it a try. Also today I won't have the time and then there's
>> > already weekend, and I won't return before late Sunday.
>> > If it breaks (should error out somewhere related to
>> > FindPackageHandleStandardArgs), please let me know.
>> > Setting cmake policy CMP0017 to NEW should fix this breakage if it
>> > occurs. This would have to be done at the top of FindKDE4Internal.cmake
>> > where the other policies are set too, inside a if(POLICY CMP0017) guard.
>> >
>> > IMO if this breakge occurs, this is something which we *must* fix before
>> > the 4.6.0 release. I spent basically months of arguing and testing about
>> > this issue with the cmake devs to get this new behaviour (without the new
>> > behaviour KDE 4.5.0/4.5.1 would have broken cmake 2.8.3, or the other way
>> > round, depending on how you see it) into cmake.
>>
>> Delaying 4.6.0 at this point due to a cmake that barely any distros
>> are using seems quite foolish to me (assuming it is an issue).
>
> No, this is not foolish.
> All distros will use cmake >= 2.8.4 in the future.

There aren't too many distros in the future that will be building
4.6.0. They will be building 4.6.1 and 4.6.2. That was my point.

If a distro with an aggressive cmake-upgrade policy does hit the
problem they can patch it at that point. 4.6.0 is going to be tagged
tonight hopefully.

Ian