From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 846B71381F3 for ; Sun, 7 Jul 2013 10:09:29 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DE31DE0931; Sun, 7 Jul 2013 10:09:25 +0000 (UTC) Received: from smtp-03.vtx.ch (smtp-03.vtx.ch [194.38.175.92]) by pigeon.gentoo.org (Postfix) with ESMTP id D32AEE08ED for ; Sun, 7 Jul 2013 10:09:24 +0000 (UTC) Received: from localhost.localdomain (dyn.83-228-133-210.dsl.vtx.ch [83.228.133.210]) by smtp-03.vtx.ch (VTX Services SA) with ESMTP id 52313298612 for ; Sun, 7 Jul 2013 12:09:22 +0200 (CEST) Date: Sun, 7 Jul 2013 12:10:29 +0200 From: Dominique Michel To: gentoo-desktop@lists.gentoo.org Subject: Re: [gentoo-desktop] Interest inquery: kde4-nosemantic overlay Message-ID: <20130707121029.73f8d939@vtxnet.ch> In-Reply-To: References: X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; x86_64-pc-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEXy8ubtkoXo7+b1+fbN cGKCeWDtamweFA8eMkmKPkPtvcWRoqyV0Pn7AAACbElEQVQ4jXXTMWvbQBQA4MOlizsdXEXp KAi09mKcLZ0EJxONDRJVkikg9AtqTm63gtHDmVJs1GsnC0JiaTMJGN2f67uzznJb+gZj9PFO 7717IqdtvCAmem4bxMLp/2BEyEBF1+U/0H8uhI6rv+BVLNrY/gH9T0L8yAxk2yMY3YuZxDCn TY/gpBByyTGktIcZOIvFjPNJmqYJDwrx3cIoBrE0zzG4FF8tfBAwM+DonKCYWjgROZ6Upjcm 5Qje58JAmlKKGfIAjzaDUuogZBY2Bjg14eDbywMIqZvwqgqFBcVFB0seYONLb00ZZlh4p0F6 FHNoUMyKAzxowJSQTyj+XloYs3MN3GeMpzyYSTMshLM00ODpWlPp4SDbqs4cViDcGAgmlK/a PsaOg7DvIQ3wzANMqB/iQW/XTkoTLO6XhSeHUoQKe+NLjyY/Ldx7CW2D4WTYhZ3V0GP64RpP Q/E66IUWMLj3+nDn4w2ejMACyXFeHZy6ETcZehc49bv1GQ/0bazNuzm97mDkhnoie9i30WYM w/YCnYT7Fx308s98n0IT//Jod1+aOzdzYXLVbftol+PC+REG3u+0AxdEtuSMB6G+DLGwMH4E vXGmJn8VCLM9LhmrOAMQYt5Wi/DFgIC52iFkUzMpDVmjAaDZRGC+JGwDqzJ/G5fUUcWZAaE7 YfvPLYtIU1Wb4A2IeS7uDMgcIFutiCr766qGfKHyuxvTIERKXVNSN27lDgCuBuojlpxIyJV6 ritS1uWWuHF2Ww7qcIKbqEFVNbmtmm3vGSCHbVXjikrY3SpVxwQWw2aIjwG+ueXTJDmHeK6a HfwGyU5ZSlGeSRQAAAAASUVORK5CYII= Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-desktop@lists.gentoo.org Reply-to: gentoo-desktop@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: c9aea6e3-1a61-429e-87d5-39ed602f7922 X-Archives-Hash: 6604b7d7c9bd5d2b000014485eebc0a4 Le Wed, 3 Jul 2013 17:32:25 +0000 (UTC), Duncan <1i5t5.duncan@cox.net> a =C3=A9crit : > 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=3D"-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. >=20 > 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. >=20 > But with a bit of luck, I won't have to switch away from kde after > all. >=20 > I already asked gentoo/kde to reconsider, given that they've supported > USE=3D-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. >=20 > But the kde-sunset overlay does suggest another alternative, a kde4- > nosemantic overlay. >=20 > 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. >=20 > 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/. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > Any interest? >=20 > 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. >=20 > 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. >=20 > 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. >=20 > So what do people think? Any interest? How should we go about it? >=20 > 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? >=20 > In particular, I expect users who are or have been active in the kde- > sunset overlay will have some useful insights. >=20 > --- > [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): >=20 > http://dilfridge.blogspot.com/2013/05/news-from-201305-gentoo-kde-team-me= eting.html >=20 > [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. >=20 --=20 "We have the heroes we deserve."