Kevin Krammer posted on Wed, 27 Mar 2013 21:54:28 +0100 as excerpted:
>> Which leaves amarok. Amarok's kde3 -> kde4 conversion was for me a
>> microcosm of the larger kde3 -> kde4 debacle. The devs tried switching
>> to mysql as akonadi was at the time, but in the process, they used
>> mysql functionality (something about a mysql library for use in other
>> apps, I've forgotten the details) that was completely broken on
>> amd64/x86_64 at the time, because as all libraries on amd64, the
>> library in question needed built with -fpic, but as that library was a
>> part of the larger mysql package and building the rest of it with -fpic
>> would have meant unacceptable slowdowns for the executables, nobody was
>> actually building it with -fpic.
>
> This is strange, could that be a Gentoo artifact?
> MySQL is officially supporting in-process for some of its backends
> (usually MyISAM) and as far as I can tell worked well for most people I
> know (but those are all Debian users).
It wasn't a gentoo artifact, but due to gentoo being reasonably leading
edge, gentoo (along with I suppose arch) was one of the first to hit it.
At the time mysql was having growing pains of its own, and this was one
of them. I wish I remember which library it was, but I believe it really
hadn't been considered an external interface until just before this, and
while amarok wasn't the first to use it, being as popular a kde app as it
was, it was the first reasonably popular app to use it. And I guess
previous use had all been 32-bit, so it really hadn't mattered. But the
mysql build scripts weren't adding -fpic for that library's build yet,
and the problem was so new people were figuring it all out in real time,
so at first, the only alternative as to build the whole mysql package
with -fpic on amd64.
But of course that slowed down the (non-library) executables, and a big
part of mysql's appeal as a database has always been performance, so all
the big data customers would have immediately protested at the loss of
that few percent in performance, and the distros were thus stuck for a
period of a few months with a broken-for-amarok mysql.
Meanwhile, amarok itself was behind kde4-core, and while kde4-core was
busy telling users that kde3 was no longer supported, amarok and other kde
non-core apps (at least k3b and kaffeine as well, that I was personally
running at the time) had yet to release stable kde4 versions -- they had
early alphas or betas out, but that was it. So users had to choose
between an unsupported kde3 core but stable kde apps, or a so-called
stable kde4-core (which was really still alpha with 4.2, beta with 4.3),
but deal with unstable pre-release non-core apps.
And I suppose the amarok devs thought it's only pre-release anyway, no
big deal if amd64 users are shut out for a bit. Except that only kde4
was supported by kde-core by then, and I guess the amarok devs didn't
consider the fact that they were locking out all their amd64 users that
had already bitten the bullet (or in my case, were trying to bite it) and
had switched to the only supported kde-core already.
Meanwhile, gentoo was still sort of supporting kde3 at the time, for
stable anyway, but they'd already announced it EOLed because upstream kde
wasn't supporting it any longer, thus signaling users like me to get our
butts in gear and move to kde4 while the moving was good. Except kde4
was still horribly broken, both core and even more the non-core apps.
I expect amd64 archlinux users had a similar problem, because both gentoo
and arch are rolling distros. Standard non-rolling distros in many cases
were still kde3 with their current stable release, and were working thru
these sorts of problems for either the immediately following release or
the one after that, depending on where they were in their cycle at the
time. That, or in a couple cases I guess the distros simply bit the
bullet and switched to kde4 (exclusively) as well, since upstream had
declared kde3 no longer supported, and what worked worked and what didn't
didn't -- they were simply going with upstream.
Anyway, there really should have been kde3 support until at least the
popular non-core kde-based apps were stable on kde4. And as I've said,
by (late) kde 4.5, pretty much everything (both kde core and non-core)
was stabilized on kde4 that was going to be, so that's what /should/ have
been 4.0 and would have been the minimum practical in ordered not to
leave users in the gap. Tho even that's pushing it, as many users aren't
ready to switch with a normal x.0 release either, and giving them a year
to switch would have meant supporting kde3 thru kde 4.7 or so. But of
course by then kdepim was going thru its betas, so it would have needed
delayed further... until 4.9 or even the current 4.10. Either that or
kdepim shouldn't have been allowed that major switch in the "stable" 4.x
series, and should have waited until 5.x to drop kmail1, etc, tho of
course the akonadified kmail2 could have been developed along side, and
people encouraged to switch when they were ready, since they'd have to do
so by kde5 in any case.
But I do accept that sometimes volunteers simply won't be herded. But in
that case, the messaging was all wrong, given the promise. But now I'm
rehashing.
> It can be hard to tell from a developer perspective if something that is
> officially supported by an upstream dependency does not work under some
> circumstances and that some of your downstreams are triggern those.
>
> Btw, isn't there a continuation of the Amarok version 1 project? I think
> it is called Clementine or something like that.
Yes. Actually, I /think/ there might be /two/ such forks, clementine and
something else.
However, by the time that came around, I guess many users had moved on.
Certainly I had, /long/ before. But I think even most stable users would
have had to move on by the time clementine was ported, stable, and the
news was out that it was an alternative, tho certainly amarok/kde4 would
have been stable by then, just the feature set wouldn't have been the
same.
>> I do sort of wish gwenview would implement audio file support, however,
>> and thus be a full media filemanager. Media files are my biggest use
>> case for user-side/full-GUI file management, and gwenview handles
>> images and video well enough that I use it almost exclusively for them,
>> but it totally hides everything else, including audio-only files, which
>> are now one of only two things I use dolphin for. The other is as a
>> trivial-case file browser, basically a file open dialog on steroids.
>
> Interesting idea, have you checked if there is a wish item report for
> that?
I haven't. The idea has only been gradually forming in my own head, as I
watch what I choose to use as a file manager and under what
circumstances. I believe this was actually the first time I've expressed
the fully formed wish-list item myself, solidifying the idea for me too,
as I wrote about it (tho I've expressed hints at it before, just not the
fully formed idea).
Thanks for the encouragement, however. I'll consider submitting it.
(But I just worked two full shifts with less than 8 hours between... and
no sleep... so my mind rebells at even /thinking/ about doing it tonite.)
BTW, I did submit a couple superkaramba patches several kde versions
ago. But they seem to have fallen thru the cracks as I've not gotten a
reply at all, to either one. Which surprises me given that it's not just
a wish, there's a patch attached for both, and if it's a rejection it'd
be nice to at least know that. Does superkaramba even have a maintainer,
or was it ported to kde4 and abandoned to die? What about for
frameworks? Since plasma supports superkaramba themes, I had assumed
they'd take an interest in it if nobody else did, but... nothing.
Anyway, if you'd take a look and poke whoever, I'd certainly appreciate
it. The patches still apply fine here. I know as I have them in the
appropriate location here on gentoo (/etc/portage/patches/kde-base/
superkaramba/<name>.patch) so they get auto-applied to every superkaramba
update I build, and the ebuild would error out if they failed to apply.
[Patch] Superkaramba cpu sensor missing wait-load
https://bugs.kde.org/show_bug.cgi?id=274906
[Patch] Superkaramba memory sensor missing buffers and cache
https://bugs.kde.org/show_bug.cgi?id=275070
--
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
___________________________________________________
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.
