[gentoo-desktop] Re: FWIW, kde-plasma/plasma-desktop and kde-plasma/plasma-workspace no-baloo enhancement bug and patches

[Michael Palimaka]

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.