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

[Duncan]

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