1 |
To be honest I see this as a huge over reaction. |
2 |
|
3 |
Its unclear from your mail if you did try running it with it disabled at |
4 |
runtime first before hacking the ebuilds... If you did not I do recommended |
5 |
it just to see how little difference it actually makes. |
6 |
|
7 |
I guess having all the hacks centralised will be useful at least though. |
8 |
|
9 |
Ian |
10 |
On 3 Jul 2013 18:33, "Duncan" <1i5t5.duncan@×××.net> wrote: |
11 |
|
12 |
> For kde-4.11, it seems the gentoo/kde project has decided to hard-enable |
13 |
> the former semantic-desktop USE flag, forcing the option on and forcing a |
14 |
> number of formerly optional additional dependencies.[1] |
15 |
> |
16 |
> But, I spent quite some time here switching away from kdepim's kmail, |
17 |
> akregator, etc, so I could kill akonadi on my system, and with it |
18 |
> semantic-desktop, etc, and I'm in no mood to have it hard-enabled now. |
19 |
> If it comes to it, I'd rather dump the kde desktop and switch to something |
20 |
> else[2], than have semantic-desktop on my system once again. |
21 |
> |
22 |
> But with a bit of luck, I won't have to switch away from kde after all. |
23 |
> |
24 |
> I already asked gentoo/kde to reconsider, given that they've supported |
25 |
> USE=-semantic-desktop until now and with 4.11 much of kde4's going into |
26 |
> maintenance mode as the upstream developer focus switches to kde5/kde- |
27 |
> frameworks, so it makes little sense to drop support for -semantic- |
28 |
> desktop now, when upstream is continuing to offer that option at least |
29 |
> thru kde4, and kde5/frameworks is supposed to be far more modular, so with |
30 |
> luck will allow users to pick and choose whether they want the |
31 |
> semantic-desktop components pulled in or not. However, given the gentoo/ |
32 |
> kde project history with dropping kde3 support and forcing kde3 users to |
33 |
> to the user-supported kde-sunset overlay even while kde4 was still not |
34 |
> ready for use (and despite upstream kde's broken promise to support kde3 |
35 |
> as long as there continued to be users), I'm not optimistic, but it was |
36 |
> worth a shot. |
37 |
> |
38 |
> But the kde-sunset overlay does suggest another alternative, a kde4- |
39 |
> nosemantic overlay. |
40 |
> |
41 |
> Meanwhile, as I upgraded to the kde-4.11 pre-releases (currently 4.10.90 |
42 |
> aka 4.11-beta2) in the kde overlay, for the kde-desktop-core and other |
43 |
> gentoo/kde packages I still run, I diffed the ebuilds between 4.10.x and |
44 |
> 4.10.80 (aka 4.11-beta1), then checked the diffs for non-semantic-desktop |
45 |
> related changes and kept them, while changing the semantic-desktop force- |
46 |
> enabling changes to force-disabling instead. |
47 |
> |
48 |
> Then I created a framework that works much like epatch_user, except |
49 |
> instead of automatically applying patches to upstream sources, it |
50 |
> automatically applies patches to gentoo ebuilds and instead of using the |
51 |
> /etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/. |
52 |
> |
53 |
> So now I have a set of ebuild patches that patch the kde 4.11 ebuilds |
54 |
> (starting with 4.10.80, aka 4.11-beta1) to force-disable semantic- |
55 |
> desktop, instead of force-enabling it. And I have a scripted framework |
56 |
> that auto-applies these patches to new ebuilds on emerge --sync and layman |
57 |
> -S, thus keeping no-semantic around as upstream gentoo/kde updates their |
58 |
> ebuilds. |
59 |
> |
60 |
> For now, therefore, I'm fine, up and running on 4.10.90 (aka 4.11-beta2), |
61 |
> using gentoo/kde ebuilds auto-patched to kill the now forced-on semantic- |
62 |
> desktop, forcing it off instead. |
63 |
> |
64 |
> But realistically, I honestly don't know if longer term, I'll be able to |
65 |
> continue maintenance of all of this by myself. Chances are unfortunately |
66 |
> high that without help from others, over time I'll decide it's simply too |
67 |
> much of a hassle maintaining the patches, and will end up switching to |
68 |
> some other desktop, with the qt-based razor-qt desktop one candidate as |
69 |
> sort of a kde-lite desktop, and enlightenment as another, getting away |
70 |
> from kde and qt entirely. |
71 |
> |
72 |
> Besides which, if I'm finding kde-nosemantic useful enough to go to all |
73 |
> this trouble, there's a good chance that others will be interested in it |
74 |
> themselves, especially if they don't have to do all the work I'm now doing |
75 |
> myself, themselves. So with kde-sunset in mind as precedent, I'm now |
76 |
> proposing a kde-nosemantic overlay, like kde-sunset, user-maintained, but |
77 |
> for kde4 folks who want a continued no-semantic choice, instead of kde3 |
78 |
> users. |
79 |
> |
80 |
> Any interest? |
81 |
> |
82 |
> To be further discussed: Assuming a go-ahead on the general idea, do we |
83 |
> want to maintain it as a normal overlay carrying at least the kde4 ebuilds |
84 |
> that require patching to kill semantic-desktop, or should we simply build |
85 |
> on the epatch_ebuild_user scripts I have hacked up, presumably checking |
86 |
> them into a git repo along with the patches themselves somewhere and |
87 |
> making that available, then simply use that tool with the existing gentoo |
88 |
> tree (when 4.11 is released and ebuilds arrive in the main tree) and kde |
89 |
> project overlay to apply the patches to the existing tree and overlay |
90 |
> instead of creating a full-fledged kde-nosemantic overlay ourselves. Of |
91 |
> course the tools and patches could then have ebuilds and appear in an |
92 |
> overlay of their own, rather than having the modified kde-nosemantic |
93 |
> ebuilds in an overlay. |
94 |
> |
95 |
> One bonus to the tools overlay instead of a direct kde-nosemantic overlay |
96 |
> approach, is that gentooers not interested in kde, but interested in the |
97 |
> ebuild-patch tools, might find that useful, add that overlay to their |
98 |
> layman overlay list, and contribute patches to the ebuild-patches tool, |
99 |
> helping it mature and grow into a general purpose automated-ebuild- |
100 |
> patching tool rather faster than it might otherwise happen. |
101 |
> |
102 |
> A hybrid alternative would be to adopt an idea much like the existing kde |
103 |
> overlay, where there's a documentation or tools directory that carries |
104 |
> them, in addition to the kde-base category and etc, carrying the patched |
105 |
> ebuilds themselves. |
106 |
> |
107 |
> So what do people think? Any interest? How should we go about it? |
108 |
> |
109 |
> Or should I just continue working on it on my own, with the likelihood |
110 |
> that at some point I'll decide it's not worth the trouble and switch to a |
111 |
> non-kde desktop, as I've switched to other non-kde tools as the kde |
112 |
> versions jumped the shark over the course of kde4? |
113 |
> |
114 |
> In particular, I expect users who are or have been active in the kde- |
115 |
> sunset overlay will have some useful insights. |
116 |
> |
117 |
> --- |
118 |
> [1] Andreas Huttel, aka gentoo dev dilfridge, covered this on his blog |
119 |
> (which is in turn covered by planet-gentoo, where I subscribe to the feed, |
120 |
> thus seeing it there): |
121 |
> |
122 |
> |
123 |
> http://dilfridge.blogspot.com/2013/05/news-from-201305-gentoo-kde-team-meeting.html |
124 |
> |
125 |
> [2] While during the early kde4 fiasco I was mostly standardized on kde |
126 |
> apps and therefore had little choice, over the course of kde4, I've |
127 |
> switched away from kde apps for first one thing than another, so by now |
128 |
> it's mostly the core kde4 desktop I depend on, plus a few other less vital |
129 |
> apps, games, dolphin, gwenview, superkaramba, that I could leave behind |
130 |
> far more easily now, if I decided I could no longer run the kde- |
131 |
> core-desktop. |
132 |
> |
133 |
> -- |
134 |
> Duncan - List replies preferred. No HTML msgs. |
135 |
> "Every nonfree program has a lord, a master -- |
136 |
> and if you use the program, he is your master." Richard Stallman |
137 |
> |
138 |
> |
139 |
> |