[kde-linux] Not installing KDE-4.5

[Duncan]

James Tyrer posted on Mon, 16 Aug 2010 07:32:53 -0700 as excerpted:

>> No doubt that a distro, with all the direct contacts to the developers
>> will soon or later come down with the solution of the problems. But for
>> a very long time that has not been the idea behind Linux !

> Well, having removed my foot from my mouth.  Who wrote those messages?
> Everywhere else:
> 
>      Found Version X, version Y (is) required
> 
> is an error message.  At least in English, if people leave out verbs,
> you tend to read as though they were there.

Well, with software, normally it's the lowest required.  Knowing that, the 
above doesn't at least to me /limit/ the version required to that, 
especially when combined with "found version X", when X>Y.  But while I'm 
basically English-only, I've been exposed to enough other cultures over 
the years that I have less problems parsing non-standard English word 
ordering and the like than many English-only users, particularly those 
without wide exposure to other cultures and ESL (English as a second 
language) speakers who may not have fully mastered standard English word 
ordering.  So it's possible I don't have the problem with it that most 
English-only, and perhaps even ESL speakers to whom standard English word 
order has been strongly emphasized, might.

What would be educational to me, at least, would be a direct contrast 
between the actual cmake requirements (and wording) where the requirement 
is a minimum version, vs. where it's a specific version.  But lacking the 
motivation and time to go digging that deeply into cmake scripting, I've 
not actually checked it, myself.

But given the nature of the issue and the chances you'll be dealing with 
it for some time, it might be worthwhile for you to check that out, and 
I'd certainly not mind you posting the comparison here... =:^)

> IAC, having use a hack to get Build LibDBusMenu-Qt-0.3.0 to build,
> 
> http://techbase.kde.org/Getting_Started/Build/KDE4/LFS#Build_LibDBusMenu-
Qt
> 
> I suppose that a patch would be more elegant, but the error was not
> immediately apparent

FWIW, I'm using libdbusmenu-qt-0.3.5 here (with kde-4.5.0).

Available in the gentoo main tree are 0.3.0, 0.3.2-r1 (-r1 denoting a 
gentoo revision bump from the first gentoo ebuild script version,  -r0 is 
implied on the original), 0.3.5, and in the kde overlay, the "live" 
version 9999 (9999 being the way gentoo denotes live versions -- they're 
always masked, however, so upgrades to them aren't done unless a user 
deliberately unmasks them).

Gentoo requirements for kdelibs-4.5 include >=libdbusmenu-qt-0.3.2.  So 
I'd suggest at least that, before trying to build 4.5.  However, it's 
possible the differences between 0.3.0 and 0.3.2 are insignificant, but 
for that one bit you hacked, so 0.3.0 may well work.

> I have KDELibs-4.5 BRANCH building as a background job.  That will take
> a while.
> 
> LibDBusMenu-Qt-0.3.5 builds correctly, but I don't know if it, or the
> other newer versions will work.

As mentioned above, it's what I used here, so it should work.  But I do 
note a patch to 0.3.5 that may be of interest, depending on the version of 
qt you're running.  It's a patch to build against qt-4.7, specifically, a 
patch checking for a specific qt feature, QIcon::name, apparently added 
late in the qt-4.7 cycle.  With qt-4.6 it's not needed, but it may be with 
qt-4.7, or maybe only with the qt-4.7 betas, I'm not sure.

> Was the message in: "kdelibs/cmake/modules/FindDBusMenuQt.cmake" in
> error or does KDE require an older version as it does with other
> dependencies?
> 
> Do you understand that attitude of the developers that apparently don't
> want build instructions available?  At least they would rather not have
> them than help we with the information needed to do it.
> 
> I will continue to try to do this (for now), but it is not simple when
> the information is not published on a web page.

I think the attitude is simply that it's the distribution's job to know 
this stuff, and that if end users are troubling themselves, it's by 
choice.  Given the few that will, and the nature of FLOSS development in 
regard to those with the itch, scratching it, the job of documenting build 
instructions is left to those that have the itch to scratch.  LFS users 
are simply about the only end users that have that itch, so...

As for distribution packagers, I believe the feeling is that for those 
packaging kde, they should be closely enough involved with upstream to be 
following developments as they happen, pretty much "live".  That's what 
gentoo/kde has ended up doing, but at the community distribution level, at 
least, it's taking a team of some decent size to do it.  For distributions 
with paid devs, kde is presumably a big enough project that they pay at 
least one maintainer to follow it full time, and it'd therefore take less 
devs to do it.  I **DO** know that it took quite some time, over a year, 
really, for the gentoo/kde team to really "catch up" to what was going on, 
sort thru all the inter-dependencies, etc, even with the sizable handful 
of people they have working on it.  Now that they're "caught up", it's 
taking somewhat less effort to maintain, but it's still no small task, by 
any means.

Which is probably why LFS doesn't maintain a script for it.  They simply 
don't have the resources.  That leaves users pretty much on their own.

Which leaves you a choice.  I mentioned earlier, James, the choice of 
trying gentoo, since the work is already being done there.  But the other 
choice you have is that since you're pretty much already doing the work, 
you might wish to contact LFS and see what it would take to do the scripts 
for LFS directly.  Then they'd /have/ those scripts.  And you'd 
potentially get more feedback and possibly development/testing cooperation 
from other LFS users as well, helping you get them right.  If you're 
already doing the work, you might as well take the final steps of 
formalizing and contributing it to your distribution of choice, and get 
the recognition for it. =:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman