Mailing List Archive

On 31/03/16 11:28, Duncan wrote:
> I've been able to patch out the (source) deps, and instead of patching
> the ebuilds themselves, I've placed those patches in the appropriate
> /etc/portage/patches/kde-plasma/plasma-[desktop|workspace]/ locations so
> the ebuilds apply them automatically, and either package.provided the
> baloo package itself to fake the dep for the ebuilds (works, but
> package.provided is deprecated), or created a fake baloo in my overlay
> that installs no files (what I'm actually doing now).
>
> That eliminates the actual baloo installation alone with the couple of
> other packages that only it pulled in on my system.

I'd say that Gentoo should not maintain their own fork of KDE. It's way
too much work. It's up to upstream to do this.

In my case, I don't need desktop search and have all that stuff disabled
in System Settings. A KDE build-time option would be useful, but I don't
think they consider this an issue, since users can disable it.

Nikos Chantziaras posted on Fri, 01 Apr 2016 07:39:04 +0300 as excerpted:

> On 31/03/16 11:28, Duncan wrote:
>> I've been able to patch out the (source) deps, and instead of patching
>> the ebuilds themselves, I've placed those patches in the appropriate
>> /etc/portage/patches/kde-plasma/plasma-[desktop|workspace]/ locations
>> so the ebuilds apply them automatically, and either package.provided
>> the baloo package itself to fake the dep for the ebuilds (works, but
>> package.provided is deprecated), or created a fake baloo in my overlay
>> that installs no files (what I'm actually doing now).
>>
>> That eliminates the actual baloo installation alone with the couple of
>> other packages that only it pulled in on my system.
>
> I'd say that Gentoo should not maintain their own fork of KDE. It's way
> too much work. It's up to upstream to do this.
>
> In my case, I don't need desktop search and have all that stuff disabled
> in System Settings. A KDE build-time option would be useful, but I don't
> think they consider this an issue, since users can disable it.

I'd hardly consider it a fork. It's a couple very trivial patches,
deleting/commenting eight lines total between the two packages that
simply disable building a couple already spun out into subdirs
functionality modules. If it were to make it optional instead of simply
deleting the config for it as I've done since I lack the knowledge to
properly make it optional, chances are the patch would change only four
lines.

Gentoo already does similar patching, making optional otherwise
"required" modules (there's even a custom helper function in the eclass
to make it easier, that I didn't choose to use both because I would have
had to read up on /them/ instead of direct patching once I figured out
what I needed to do, and because as that would have involved patching the
ebuild, far harder to maintain as a user on gentoo than the fully
automated source patching), as well as far more invasive patching in some
cases. To the extent that is considered forking, it's already well
forked, and these patches won't change that either way.

Tho you're correct in that taking it upstream, to the extent upstream is
receptive to the idea at all, is by far the best option. But as you
mention, not all upstreams are interested.

But I already got the result I expected (and explicitly offered as a
choice if gentoo/kde didn't want to go that way) on the bug, resolved
UPSTREAM. However, filing the bug served a couple purposes. It
demonstrated how simple a change it is, and publicly presented the option
for gentoo/kde to look at, number one.

Number two, the patches are now out there and known to work for at least
the bug reporter, in a centralized place for other users who wish to make
use of them, even tho gentoo/kde has chosen not to, at this point. I
know there's quite a few patches I've found on bugzilla and applied
locally, made available by other users who came across the same problem
and found a solution, before the package maintainers chose to apply,
sometimes with further modifications, or reject, the same patches. I've
simply returned the favor here.

This second purpose was at least as important as the first, and now the
patches are out there for others who can choose to apply them locally or
not, given that gentoo/kde has chosen not to apply them as the direct
upstream of those gentoo/kde users. Plus, while the patches are trivial
enough that finding them for non-gentooers choosing to build from sources
may be more work than simply redoing them on their own, unlike the
initial case for people doing them on their own, these are now tested and
known to work.

I'm not sure whether I'll try to take them upstream or not. I've
submitted previous kde package patches to bugzilla.kde, that never even
got a comment from the kde dev. Still, doing so for the #2 reason, to
make them available to other users who may look for them, is just as
important. But I'd really need to understand better the cmake build
system and/or how kde uses it, in ordered to properly make the components
a build-time option instead of simply hard-disabling them at build-time,
as the current patches do. IOW, the current patches are sysadmin and
targeted binary-distro level, giving builders with specific deployment
needs in mind a way to disable the otherwise required feature. They
really need to be improved to make the currently required feature
optional, instead, to be of interest to upstream devs (and the gentoo
reply said as much as well), and I don't currently know how to do that
properly. Given that the current patches work at the targeted build
level, however, they work for me, and I'm not sure it's worth the trouble
of learning the cmake system just to submit it upstream, where given past
patch submission experience, it may sit without even a dev comment.

I suppose it's like much else, including submission at the gentoo level.
If I get time and don't have anything else more interesting to do, as I
did for the gentoo submission, I'll submit it at the kde level as well.
Otherwise, I'll simply continue applying the patch locally, and probably
updating the gentoo bug in case anyone's using the patches there, when
need be as well.

--
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

On 01/04/16 19:05, Duncan wrote:
> Nikos Chantziaras posted on Fri, 01 Apr 2016 07:39:04 +0300 as excerpted:
>
>> On 31/03/16 11:28, Duncan wrote:
>>> I've been able to patch out the (source) deps, and instead of patching
>>> the ebuilds themselves, I've placed those patches in the appropriate
>>> /etc/portage/patches/kde-plasma/plasma-[desktop|workspace]/ locations
>>> so the ebuilds apply them automatically, and either package.provided
>>> the baloo package itself to fake the dep for the ebuilds (works, but
>>> package.provided is deprecated), or created a fake baloo in my overlay
>>> that installs no files (what I'm actually doing now).
>>>
>>> That eliminates the actual baloo installation alone with the couple of
>>> other packages that only it pulled in on my system.
>>
>> I'd say that Gentoo should not maintain their own fork of KDE. It's way
>> too much work. It's up to upstream to do this.
>>
>> In my case, I don't need desktop search and have all that stuff disabled
>> in System Settings. A KDE build-time option would be useful, but I don't
>> think they consider this an issue, since users can disable it.
>
> I'd hardly consider it a fork. It's a couple very trivial patches,
> deleting/commenting eight lines total between the two packages that
> simply disable building a couple already spun out into subdirs
> functionality modules. If it were to make it optional instead of simply
> deleting the config for it as I've done since I lack the knowledge to
> properly make it optional, chances are the patch would change only four
> lines.
>
> Gentoo already does similar patching, making optional otherwise
> "required" modules (there's even a custom helper function in the eclass
> to make it easier, that I didn't choose to use both because I would have
> had to read up on /them/ instead of direct patching once I figured out
> what I needed to do, and because as that would have involved patching the
> ebuild, far harder to maintain as a user on gentoo than the fully
> automated source patching), as well as far more invasive patching in some
> cases. To the extent that is considered forking, it's already well
> forked, and these patches won't change that either way.

While we indeed do some downstream patching and dependency mangling in
some KDE packages, we try to stay as close to upstream as possible. What
we do modify is mostly build-time only stuff, such as tests or handbooks
and should not have much affect on the user experience.

> Tho you're correct in that taking it upstream, to the extent upstream is
> receptive to the idea at all, is by far the best option. But as you
> mention, not all upstreams are interested.

If I understand correctly, at least part of the Plasma team does not
view optional dependencies as something that should be toggled lightly.
Rather, they would prefer they are always enabled unless being built on
a platform where that dependency doesn't make sense.

While I am too personally in favour of as much being optional as
possible, I certainly appreciate their view - more options means more
complex code, more codepaths and more possibility for breakage. It's
been found in the past that many packages with optional dependencies
failed to build when those optional dependencies were missing, simply
because nobody has that configuration to test with.

As such, I doubt upstream will be interesting in making such a major
feature as Baloo optional at build time.

> But I already got the result I expected (and explicitly offered as a
> choice if gentoo/kde didn't want to go that way) on the bug, resolved
> UPSTREAM. However, filing the bug served a couple purposes. It
> demonstrated how simple a change it is, and publicly presented the option
> for gentoo/kde to look at, number one.

In addition to sticking to upstream, I note it's easy to turn off at
runtime if unwanted and baloo:5 has a much lighter deptree than baloo:4.

> Number two, the patches are now out there and known to work for at least
> the bug reporter, in a centralized place for other users who wish to make
> use of them, even tho gentoo/kde has chosen not to, at this point. I
> know there's quite a few patches I've found on bugzilla and applied
> locally, made available by other users who came across the same problem
> and found a solution, before the package maintainers chose to apply,
> sometimes with further modifications, or reject, the same patches. I've
> simply returned the favor here.
>
> This second purpose was at least as important as the first, and now the
> patches are out there for others who can choose to apply them locally or
> not, given that gentoo/kde has chosen not to apply them as the direct
> upstream of those gentoo/kde users. Plus, while the patches are trivial
> enough that finding them for non-gentooers choosing to build from sources
> may be more work than simply redoing them on their own, unlike the
> initial case for people doing them on their own, these are now tested and
> known to work.

Even though we weren't able to integrate your changes, thanks for your
work. It's interesting to know how simple it actually is and I'm sure
there's others who will find it useful too.

Michael Palimaka posted on Sun, 03 Apr 2016 04:05:13 +1000 as excerpted:

[snippy-snip]

> If I understand correctly, at least part of the Plasma team does not
> view optional dependencies as something that should be toggled lightly.
> Rather, they would prefer they are always enabled unless being built on
> a platform where that dependency doesn't make sense.
>
> While I am too personally in favour of as much being optional as
> possible, I certainly appreciate their view - more options means more
> complex code, more codepaths and more possibility for breakage. It's
> been found in the past that many packages with optional dependencies
> failed to build when those optional dependencies were missing, simply
> because nobody has that configuration to test with.

Of course this is one reason why even much of the FLOSS world considers
gentooers insane.

Of course we have our reasons, but equally importantly, viewed from a
different angle, "exercising" those optional dependencies is valuable,
for much the same reason attempting to build with llvm and friends, even
if you don't recommend it for production use and default to gcc, is
valuable. Similarly, building on all those exotic archs. In each case,
while the benefit is arguably limited and may not in itself be worth the
hassle, in the end it finds bugs, and patching them makes for a much
stronger product all around, including when built with all recommended
deps, with the default toolchain, on the most mainstream arch and OS of
them all (generally considered to be 64-bit x86 for gnu/linux, these
days, tho arguably only because the arm processors android/linux is
normally deployed on are far more varied than x86, or they'd certainly
take that crown)

> As such, I doubt upstream will be interesting in making such a major
> feature as Baloo optional at build time.

As long as they keep it modular enough to continue hard-disabling via
patch, where desired, without seriously increasing the complexity of the
process. At this level on kde/frameworks/plasma5 it's a couple simple
patches, but I doubt gentoo would have tried it with the far more complex
and less modular kde4 if it hadn't been supported upstream, in which case
I wouldn't have had anything to continue to base patches on during the
period when gentoo/kde quit supporting it on kde4, and I *KNOW* it was
/way/ beyond my skills without being able to lean on gentoo's patches,
back on kde4.

But at least for the time being it's extremely simple for kde/frameworks/
plasma5, and as long as it stays that way, not a problem.

If it ever gets out of hand, well, I've always said that one way or
another, the file indexer isn't going to be running long on my desktop
(temporarily exception for porting and working out all the deps allowed
and taken). As long as I can arrange to kill the deps in kde, I'll
likely keep the kde desktop. If that becomes no longer possible, there's
a very good chance, I'd say 80% or better, I'll be off of kde entirely
within a year. Back before the turn of the century I was running MS
betas and was inline at midnight for MS Windows 98. Then the eXPrivacy
malware crossed a line I wouldn't cross, and I became nearly as
proficient on Linux in three months as I had done on MS in nearly a
decade.

Similarly, back in the kde3 era I was very nearly fully standardized on
kde, wondering if I could switch a couple more apps and avoid gtk on my
system at all. During the fiasco that was the switch to kde4 I switched
to non-kde for some of it, and switched even more when they broke kmail
with akonadi, and when a couple potential security issues in konqueror
went unfixed for way too long, and it became apparent they were treating
it more like a toy than something serious that people could properly do
their banking and etc on. They even broke global hotkey chaining in kde4,
so I had to switch my hotkey setup to something else, and thus didn't
really have to worry about it in the kde5 upgrade (except for kde hotkeys
themselves, kwin-based zoom, invoking the cube, etc, session logout, kmix
hotkeys, etc, but if I dump plasma those go with it and I configure
whatever I replace plasma and kwin with, with my hotkeys).

So now, other than the desktop itself, some kdegames, gwenview, and
superkaramba, I'm pretty much off of kde, which is why it's relatively
easy to run the live-9999 testing version of the parts of kde I do have
installed. And of course superkaramba is now a dead package upstream, so
while it's working for now, I'll have to find a replacement for it within
a year or so. I already have a replacement for gwenview, that I used
when gwenview was broken for me for a time. And the games I can either
do without, find replacements for, or install individually. Which means
it's pretty much only the desktop.

So as I said, if at some point they interweave baloo into the desktop to
the point I can't unweave it, I'll probably be off it too, within a year
and most likely within 2-4 months.

> In addition to sticking to upstream, I note it's easy to turn off at
> runtime if unwanted and baloo:5 has a much lighter deptree than baloo:4.

That is /definitely/ true. =:^)

But of course it doesn't help when baloo isn't building with current
cmake. I had a bug on that (as I expect you're aware but others here may
not be), but it turned out that was simply more motivation to figure out
how to kill baloo, given that several cmake upgrades over some months
hadn't fixed it, so it looked like I was either going to have to
seriously dig into it myself or dig into figuring out how to kill that
dep, which was my ultimate goal anyway, so when I had the time to spend,
it's obvious where I spent it.


But truth be told, if there wasn't so much bad water under the bridge
with the still horribly broken semantic-desktop crammed down our throats
in the kde4 era, with it being easier to fully disable at runtime in kde/
plasma5, I'd have 90% chance been satisfied with just that, and would
have been far more likely to jump thru the hoops the other way with the
baloo building bug, tracing it down instead of making it my job to figure
out how to exterminate baloo, even if I do find it worse than useless
when actually running (since I find very nearly useless, it's very nearly
worthless to me, even were it able to run at zero resource cost, but of
course it's not zero resource cost, in either CPU time or indexing space,
so the already nearly worthless actually ends up well into the negative).

> Even though we weren't able to integrate your changes, thanks for your
> work. It's interesting to know how simple it actually is and I'm sure
> there's others who will find it useful too.

Thanks. Like I said, getting it out there for anyone else that found it
useful in the absence of gentoo/kde taking it, was at least as important
to me as getting an answer one way or the other on whether gentoo/kde
/would/ take it, particularly since I figured I pretty much knew the
answer to the latter already. Tho it never hurts to ask, particularly
when there's further reasons for posting as well. =:^)

--
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