[gentoo-desktop] Interest inquery: kde4-nosemantic overlay

[Duncan]

For kde-4.11, it seems the gentoo/kde project has decided to hard-enable
the former semantic-desktop USE flag, forcing the option on and forcing a
number of formerly optional additional dependencies.[1]

But, I spent quite some time here switching away from kdepim's kmail,
akregator, etc, so I could kill akonadi on my system, and with it
semantic-desktop, etc, and I'm in no mood to have it hard-enabled now.
If it comes to it, I'd rather dump the kde desktop and switch to something
else[2], than have semantic-desktop on my system once again.

But with a bit of luck, I won't have to switch away from kde after all.

I already asked gentoo/kde to reconsider, given that they've supported
USE=-semantic-desktop until now and with 4.11 much of kde4's going into
maintenance mode as the upstream developer focus switches to kde5/kde-
frameworks, so it makes little sense to drop support for -semantic-
desktop now, when upstream is continuing to offer that option at least
thru kde4, and kde5/frameworks is supposed to be far more modular, so with
luck will allow users to pick and choose whether they want the
semantic-desktop components pulled in or not.  However, given the gentoo/
kde project history with dropping kde3 support and forcing kde3 users to
to the user-supported kde-sunset overlay even while kde4 was still not
ready for use (and despite upstream kde's broken promise to support kde3
as long as there continued to be users), I'm not optimistic, but it was
worth a shot.

But the kde-sunset overlay does suggest another alternative, a kde4-
nosemantic overlay.

Meanwhile, as I upgraded to the kde-4.11 pre-releases (currently 4.10.90
aka 4.11-beta2) in the kde overlay, for the kde-desktop-core and other
gentoo/kde packages I still run, I diffed the ebuilds between 4.10.x and
4.10.80 (aka 4.11-beta1), then checked the diffs for non-semantic-desktop
related changes and kept them, while changing the semantic-desktop force-
enabling changes to force-disabling instead.

Then I created a framework that works much like epatch_user, except
instead of automatically applying patches to upstream sources, it
automatically applies patches to gentoo ebuilds and instead of using the
/etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/.

So now I have a set of ebuild patches that patch the kde 4.11 ebuilds
(starting with 4.10.80, aka 4.11-beta1) to force-disable semantic-
desktop, instead of force-enabling it.  And I have a scripted framework
that auto-applies these patches to new ebuilds on emerge --sync and layman
-S, thus keeping no-semantic around as upstream gentoo/kde updates their
ebuilds.

For now, therefore, I'm fine, up and running on 4.10.90 (aka 4.11-beta2),
using gentoo/kde ebuilds auto-patched to kill the now forced-on semantic-
desktop, forcing it off instead.

But realistically, I honestly don't know if longer term, I'll be able to
continue maintenance of all of this by myself.  Chances are unfortunately
high that without help from others, over time I'll decide it's simply too
much of a hassle maintaining the patches, and will end up switching to
some other desktop, with the qt-based razor-qt desktop one candidate as
sort of a kde-lite desktop, and enlightenment as another, getting away
from kde and qt entirely.

Besides which, if I'm finding kde-nosemantic useful enough to go to all
this trouble, there's a good chance that others will be interested in it
themselves, especially if they don't have to do all the work I'm now doing
myself, themselves.  So with kde-sunset in mind as precedent, I'm now
proposing a kde-nosemantic overlay, like kde-sunset, user-maintained, but
for kde4 folks who want a continued no-semantic choice, instead of kde3
users.

Any interest?

To be further discussed:  Assuming a go-ahead on the general idea, do we
want to maintain it as a normal overlay carrying at least the kde4 ebuilds
that require patching to kill semantic-desktop, or should we simply build
on the epatch_ebuild_user scripts I have hacked up, presumably checking
them into a git repo along with the patches themselves somewhere and
making that available, then simply use that tool with the existing gentoo
tree (when 4.11 is released and ebuilds arrive in the main tree) and kde
project overlay to apply the patches to the existing tree and overlay
instead of creating a full-fledged kde-nosemantic overlay ourselves.  Of
course the tools and patches could then have ebuilds and appear in an
overlay of their own, rather than having the modified kde-nosemantic
ebuilds in an overlay.

One bonus to the tools overlay instead of a direct kde-nosemantic overlay
approach, is that gentooers not interested in kde, but interested in the
ebuild-patch tools, might find that useful, add that overlay to their
layman overlay list, and contribute patches to the ebuild-patches tool,
helping it mature and grow into a general purpose automated-ebuild-
patching tool rather faster than it might otherwise happen.

A hybrid alternative would be to adopt an idea much like the existing kde
overlay, where there's a documentation or tools directory that carries
them, in addition to the kde-base category and etc, carrying the patched
ebuilds themselves.

So what do people think?  Any interest?  How should we go about it?

Or should I just continue working on it on my own, with the likelihood
that at some point I'll decide it's not worth the trouble and switch to a
non-kde desktop, as I've switched to other non-kde tools as the kde
versions jumped the shark over the course of kde4?

In particular, I expect users who are or have been active in the kde-
sunset overlay will have some useful insights.

---
[1] Andreas Huttel, aka gentoo dev dilfridge, covered this on his blog
(which is in turn covered by planet-gentoo, where I subscribe to the feed,
thus seeing it there):

http://dilfridge.blogspot.com/2013/05/news-from-201305-gentoo-kde-team-meeting.html

[2] While during the early kde4 fiasco I was mostly standardized on kde
apps and therefore had little choice, over the course of kde4, I've
switched away from kde apps for first one thing than another, so by now
it's mostly the core kde4 desktop I depend on, plus a few other less vital
apps, games, dolphin, gwenview, superkaramba, that I could leave behind
far more easily now, if I decided I could no longer run the kde-
core-desktop.

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