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

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.
>=20
> 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.
>=20
> In my case, I don't need desktop search and have all that stuff disable=
d
> 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,=20
deleting/commenting eight lines total between the two packages that=20
simply disable building a couple already spun out into subdirs=20
functionality modules.  If it were to make it optional instead of simply=20
deleting the config for it as I've done since I lack the knowledge to=20
properly make it optional, chances are the patch would change only four=20
lines.

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

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

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

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

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

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

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

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