1 |
<Resend after subscribe> |
2 |
Duncan wrote: |
3 |
> For kde-4.11, it seems the gentoo/kde project has decided to hard-enable |
4 |
> the former semantic-desktop USE flag, forcing the option on and forcing a |
5 |
> number of formerly optional additional dependencies.[1] |
6 |
> |
7 |
> But, I spent quite some time here switching away from kdepim's kmail, |
8 |
> akregator, etc, so I could kill akonadi on my system, and with it |
9 |
> semantic-desktop, etc, and I'm in no mood to have it hard-enabled now. |
10 |
> If it comes to it, I'd rather dump the kde desktop and switch to something |
11 |
> else[2], than have semantic-desktop on my system once again. |
12 |
|
13 |
I *totally* concur. After finally getting rid of KMail, it took me 9 months |
14 |
to work out and feel comfortable with mutt[1], and then it was much less of a |
15 |
step to get rid of nubkit, as well as semantic-craptop. |
16 |
|
17 |
Finally, at 4.9 my KDE has come back to me, and feels as slick as 3.5 :-) |
18 |
|
19 |
That's progress for ya.. ;p |
20 |
|
21 |
> But with a bit of luck, I won't have to switch away from kde after all. |
22 |
.. |
23 |
> Meanwhile, as I upgraded to the kde-4.11 pre-releases (currently 4.10.90 |
24 |
> aka 4.11-beta2) in the kde overlay, for the kde-desktop-core and other |
25 |
> gentoo/kde packages I still run, I diffed the ebuilds between 4.10.x and |
26 |
> 4.10.80 (aka 4.11-beta1), then checked the diffs for non-semantic-desktop |
27 |
> related changes and kept them, while changing the semantic-desktop force- |
28 |
> enabling changes to force-disabling instead. |
29 |
> |
30 |
> Then I created a framework that works much like epatch_user, except |
31 |
> instead of automatically applying patches to upstream sources, it |
32 |
> automatically applies patches to gentoo ebuilds and instead of using the |
33 |
> /etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/. |
34 |
|
35 |
Hmm that's quite interesting. Not something I'd personally want in the tree, |
36 |
but definitely of interest to more advanced admins, as opposed to end-users. |
37 |
|
38 |
(Yeah, we're all admins. Still, I don't administer a large network, and I |
39 |
don't call myself a sys-admin. I just appreciate good infra.) |
40 |
|
41 |
> So now I have a set of ebuild patches that patch the kde 4.11 ebuilds |
42 |
> (starting with 4.10.80, aka 4.11-beta1) to force-disable semantic- |
43 |
> desktop, instead of force-enabling it. And I have a scripted framework |
44 |
> that auto-applies these patches to new ebuilds on emerge --sync and layman |
45 |
> -S, thus keeping no-semantic around as upstream gentoo/kde updates their |
46 |
> ebuilds. |
47 |
|
48 |
Have to say I think I'd prefer this as a semi-automatically generated overlay. |
49 |
ie apply the patches, and if they work, let the maintainer confirm after |
50 |
testing. |
51 |
|
52 |
> For now, therefore, I'm fine, up and running on 4.10.90 (aka 4.11-beta2), |
53 |
> using gentoo/kde ebuilds auto-patched to kill the now forced-on semantic- |
54 |
> desktop, forcing it off instead. |
55 |
> |
56 |
> But realistically, I honestly don't know if longer term, I'll be able to |
57 |
> continue maintenance of all of this by myself. Chances are unfortunately |
58 |
> high that without help from others, over time I'll decide it's simply too |
59 |
> much of a hassle maintaining the patches |
60 |
|
61 |
Indeed. You shouldn't be doing this alone, over the longer-term: it'll just |
62 |
burn you out. |
63 |
|
64 |
> Besides which, if I'm finding kde-nosemantic useful enough to go to all |
65 |
> this trouble, there's a good chance that others will be interested in it |
66 |
> themselves, especially if they don't have to do all the work I'm now doing |
67 |
> myself, themselves. So with kde-sunset in mind as precedent, I'm now |
68 |
> proposing a kde-nosemantic overlay, like kde-sunset, user-maintained, but |
69 |
> for kde4 folks who want a continued no-semantic choice, instead of kde3 |
70 |
> users. |
71 |
> |
72 |
> Any interest? |
73 |
|
74 |
Hell yeah :-)[2] You picked an odd forum for it though: I only found out about |
75 |
this because Dominique posted to pro-audio list. |
76 |
|
77 |
> To be further discussed: Assuming a go-ahead on the general idea, do we |
78 |
> want to maintain it as a normal overlay carrying at least the kde4 ebuilds |
79 |
> that require patching to kill semantic-desktop |
80 |
|
81 |
Yes, as above. I much prefer the traceability of an overlay with conventional |
82 |
ebuilds in it. If we're going to do this, let's do it right. |
83 |
|
84 |
> 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 |
88 |
.. |
89 |
> One bonus to the tools overlay instead of a direct kde-nosemantic overlay |
90 |
> approach, is that gentooers not interested in kde, but interested in the |
91 |
> ebuild-patch tools, might find that useful, add that overlay to their |
92 |
> layman overlay list, and contribute patches to the ebuild-patches tool, |
93 |
> helping it mature and grow into a general purpose automated-ebuild- |
94 |
> patching tool rather faster than it might otherwise happen. |
95 |
|
96 |
Yes, the tools should be available in their own right. |
97 |
|
98 |
Tho that was an awfully long-winded way of saying "Ebuild-patch tools could |
99 |
well be of wider interest." ;) |
100 |
|
101 |
> A hybrid alternative would be to adopt an idea much like the existing kde |
102 |
> overlay, where there's a documentation or tools directory that carries |
103 |
> them, in addition to the kde-base category and etc, carrying the patched |
104 |
> ebuilds themselves. |
105 |
|
106 |
That sounds ideal, but why not just have two overlays? One for ebuild-patch |
107 |
which others can use and collaborate around, and one conventional kde-lean |
108 |
for people who want the end-product. |
109 |
|
110 |
After all, ebuild-patch tools are strictly for maintainers, and people who |
111 |
want to experiment on their system. The output ebuilds have an orthogonal use. |
112 |
|
113 |
I'd ask that we collaborate on the forums[2] about this: things can move much |
114 |
quicker there, and you get general encouragement and lots of bug feedback, |
115 |
as well as others to help. |
116 |
|
117 |
creaker patched kdelibs, as you'll see, already, and he's interested in |
118 |
working on the overlay ("Without overlay it may be boring to do the things |
119 |
I did before on every update.") So between the two of you, and as others |
120 |
get involved, I'm sure it can be done. As you said, KDE-4 is practically |
121 |
EOL, given that more developer focus is on 5. |
122 |
|
123 |
I can get the overlays, git and trac setup, same as we did for hardened a few |
124 |
years ago, if that helps. |
125 |
|
126 |
Regards, |
127 |
steveL. |
128 |
|
129 |
[1] Kmail to mutt with Maildir and procmail: |
130 |
http://forums.gentoo.org/viewtopic-t-945868.html |
131 |
|
132 |
[2] How to opt out of a semantic-desktop? |
133 |
http://forums.gentoo.org/viewtopic-t-963504.html |
134 |
-- |
135 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |