Re: Interest inquery: kde4-nosemantic overlay

Dominique Michel <[email protected]> Sun, 7 Jul 2013 12:10:29 +0200
Newsgroups gmane.linux.gentoo.desktop
Message-ID <[email protected]>
Le Wed, 3 Jul 2013 17:32:25 +0000 (UTC),
Duncan <[email protected]> a écrit :

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

With USE="-consolekit -policykit -semantic-desktop -udisks
-udisks2 -upowe", I get ride of both *kit and semantic-desktop in kde,
and of the whole of gnome as a bonus. -:)

I have only parts of kde in my system, but I made such a profile for
the pro-audio overlay, and no user complained it was not working. It is
another one as generic dekstop profile.

The main concern was *kit, which is mandatory with only very few
desktops like Gnome, but is enabled into all the gentoo desktop
profiles -:(. When I see it was possible to speed up kde by removing the
semantic desktop, I did a desktop-kde profile too.

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


-- 
"We have the heroes we deserve."