Gentoo Archives: gentoo-desktop

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-desktop@l.g.o
Subject: [gentoo-desktop] Re: kde-lean ;)
Date: Thu, 11 Jul 2013 16:45:55
Message-Id: pan$6fee4$e239c834$7406f263$c98f885d@cox.net
In Reply to: [gentoo-desktop] kde-lean ;) by "Steven J. Long"
1 Steven J. Long posted on Thu, 11 Jul 2013 13:59:32 +0100 as excerpted:
2
3 > <Resend after subscribe>
4 > Duncan wrote:
5 >> For kde-4.11, it seems the gentoo/kde project has decided to
6 >> hard-enable the former semantic-desktop USE flag, forcing the option on
7 >> and forcing a number of formerly optional additional dependencies.[1]
8 >>
9 >> But, I spent quite some time here switching away from kdepim's kmail,
10 >> akregator, etc, so I could kill akonadi on my system, and with it
11 >> semantic-desktop, etc, and I'm in no mood to have it hard-enabled now.
12 >> If it comes to it, I'd rather dump the kde desktop and switch to
13 >> something else[2], than have semantic-desktop on my system once again.
14 >
15 > I *totally* concur. After finally getting rid of KMail, it took me 9
16 > months to work out and feel comfortable with mutt[1], and then it was
17 > much less of a step to get rid of nubkit, as well as semantic-craptop.
18 >
19 > Finally, at 4.9 my KDE has come back to me, and feels as slick as 3.5
20 > :-)
21
22 It was kde 4.7 for me, but I definitely know the feeling. There's more
23 that could be said on that theme, but I guess for anyone interested in
24 this thread, it's preaching to the choir. Suffice it to say that none of
25 us greeted that gentoo/kde announcement with rejoicing, to say the least,
26 but... (vvv)
27
28 > That's progress for ya.. ;p
29
30 (^^^) ... =:^(
31
32 >> Then I created a framework that works much like epatch_user, except
33 >> instead of automatically applying patches to upstream sources, it
34 >> automatically applies patches to gentoo ebuilds and instead of using
35 >> the /etc/portage/patches/ tree, it uses /etc/portage/patches.ebuild/.
36 >
37 > Hmm that's quite interesting. Not something I'd personally want in the
38 > tree, but definitely of interest to more advanced admins, as opposed to
39 > end-users.
40
41 Of course, as I guess you'll recall (you've been around long enough I
42 think) that's what was originally said about epatch_user as well...
43
44 > (Yeah, we're all admins. Still, I don't administer a large network, and
45 > I don't call myself a sys-admin. I just appreciate good infra.)
46
47 I definitely call myself a sysadmin. It's my stated opinion that if
48 people were to take the job of administering their own systems as
49 seriously as a sysadmin does or should do (and I definitely do), then
50 we'd not have the problem with malware that we do, as there'd always be
51 insecure systems, but like a well immunized population, the immunity
52 level of the population as a whole would mean the number of infectible
53 hosts would be below that required for viable propagation, and the
54 infections simply wouldn't spread as there wouldn't be enough vulnerable
55 systems within reach for them to spread to.
56
57 Administrating a computer system is a serious job, and the more people
58 that consider it so, the less danger everyone, both those that treat the
59 job seriously and those who don't, are in.
60
61 So yes, I'm definitely a sysadmin, even if it's only for a couple
62 systems. And yes, I take that job seriously, even if I'm not paid for it
63 because they're my own systems, administered as a hobby.
64
65
66 Meanwhile, before "ebuild_patch_user" gets to the point that it's
67 acceptable in mainline (if it /ever/ gets to the point that it's
68 acceptable in mainline), just as epatch_user, time and many rounds of
69 revision (and an appropriate level of verbosity saying an ebuild was
70 modified in emerge --info <pkg>, for posting with bugs) will be needed.
71
72 >> So now I have a set of ebuild patches that patch the kde 4.11 ebuilds
73 >> (starting with 4.10.80, aka 4.11-beta1) to force-disable semantic-
74 >> desktop, instead of force-enabling it. And I have a scripted framework
75 >> that auto-applies these patches to new ebuilds on emerge --sync and
76 >> layman -S, thus keeping no-semantic around as upstream gentoo/kde
77 >> updates their ebuilds.
78 >
79 > Have to say I think I'd prefer this as a semi-automatically generated
80 > overlay. ie apply the patches, and if they work, let the maintainer
81 > confirm after testing.
82
83 If the target audience is to include the less experienced, as you're
84 hinting at, then ultimately I must agree.
85
86 >> For now, therefore, I'm fine, up and running on 4.10.90 (aka
87 >> 4.11-beta2), using gentoo/kde ebuilds auto-patched to kill the now
88 >> forced-on semantic- desktop, forcing it off instead.
89 >>
90 >> But realistically, I honestly don't know if longer term, I'll be able
91 >> to continue maintenance of all of this by myself.
92 >
93 > Indeed. You shouldn't be doing this alone, over the longer-term: it'll
94 > just burn you out.
95
96 So we agree. =:^)
97
98 >> Besides which, if I'm finding kde-nosemantic useful enough to go to all
99 >> this trouble, there's a good chance that others will be interested in
100 >> it themselves, especially if they don't have to do all the work I'm now
101 >> doing myself, themselves. So with kde-sunset in mind as precedent, I'm
102 >> now proposing a kde-nosemantic overlay, like kde-sunset,
103 >> user-maintained, but for kde4 folks who want a continued no-semantic
104 >> choice, instead of kde3 users.
105 >>
106 >> Any interest?
107 >
108 > Hell yeah :-)[2] You picked an odd forum for it though: I only found out
109 > about this because Dominique posted to pro-audio list.
110
111 I picked this list/forum for a couple (related) reasons, in addition to
112 convenience (I was already subscribed).
113
114 1) It's the coordinating list for kde-sunset, and this seemed a
115 reasonably similar project, so using the same list seemed appropriate.
116
117 2) This list is also where the gentoo/kde project posts meeting
118 announcements and sometimes summaries, etc.
119
120 Together those make this list more or less the all-things-kde list (not
121 excluding the more general desktop bit, but particularly for those
122 interested in kde...), and it seemed to me to make this the logical place
123 to post, certainly for an initial feeler.
124
125 >> To be further discussed: Assuming a go-ahead on the general idea, do
126 >> we want to maintain it as a normal overlay carrying at least the kde4
127 >> ebuilds that require patching to kill semantic-desktop
128 >
129 > Yes, as above. I much prefer the traceability of an overlay with
130 > conventional ebuilds in it. If we're going to do this, let's do it
131 > right.
132
133 OK, barring any strong feeling posted to the contrary... WORKSFORME. =:^)
134
135 > Yes, the tools should be available in their own right.
136 >
137 > Tho that was an awfully long-winded way of saying "Ebuild-patch tools
138 > could well be of wider interest." ;)
139
140 I blame all those "minimum 2 pages" (replacing 2 with a larger number as
141 I advanced) assignments in school, when two paragraphs totaling half a
142 page would have well sufficed. All those years of schooling forcing
143 rediculous verbosity... and I hit "real life" and everybody's saying
144 tl;dr! Talk about schools teaching the wrong thing!
145
146 >> A hybrid alternative would be to adopt an idea much like the existing
147 >> kde overlay, where there's a documentation or tools directory that
148 >> carries them, in addition to the kde-base category and etc, carrying
149 >> the patched ebuilds themselves.
150 >
151 > That sounds ideal, but why not just have two overlays? One for
152 > ebuild-patch which others can use and collaborate around, and one
153 > conventional kde-lean for people who want the end-product.
154
155 kde-lean definitely beats kde-nosemantic, my working title.
156
157 As for ebuild-patch, an overlay just for it? What about setting up a git
158 repo somewhere (github's popular, but not open source...) and putting the
159 ebuild for it, presumably using git2.eclass for a live-9999 version, in
160 the sunrise overlay? Once it gets mature enough to tag, if we don't want
161 to bother with a tarball, a versioned ebuild can still use the git
162 infrastructure, and simply checkout a specific tag.
163
164 > After all, ebuild-patch tools are strictly for maintainers, and people
165 > who want to experiment on their system. The output ebuilds have an
166 > orthogonal use.
167
168 Agreed.
169
170 > I'd ask that we collaborate on the forums[2] about this: things can move
171 > much quicker there, and you get general encouragement and lots of bug
172 > feedback, as well as others to help.
173
174 I've actually seen lists/newsgroups move in very close to real-time -- as
175 close as I generally care to get (I don't do IRC as I like a bit more
176 time to compose my posts).
177
178 But, web-forums do seem to be more popular, and I guess I could dust off
179 my old forum login or create a new one...
180
181 > creaker patched kdelibs, as you'll see, already, and he's interested in
182 > working on the overlay ("Without overlay it may be boring to do the
183 > things I did before on every update.") So between the two of you, and as
184 > others get involved, I'm sure it can be done. As you said, KDE-4 is
185 > practically EOL, given that more developer focus is on 5.
186 >
187 > I can get the overlays, git and trac setup, same as we did for hardened
188 > a few years ago, if that helps.
189
190 That would be useful.
191
192 Person to person, let me also say I'm absolutely thrilled to have you
193 helping. I didn't know you were a kde-er so thought it a bit much to
194 hope for, but I definitely consider your bash skills well above mine
195 (you're the name that comes to mind when the words "bash coder" get
196 used), and have little doubt that you'll be able to beat my poor hacks
197 that work on my system but that I wouldn't consider secure or robust
198 enough for general purpose use into much better general-purpose shape,
199 far faster/better than I could.
200
201 And I expect quite apart from improving the tools themselves, I'll learn
202 quite a lot from the process, and my next project will be rather higher
203 (dare I say professional?) quality early code as a result. I certainly
204 can't argue with that! =:^)
205
206 Of course there's other than shell/bash, but that's the scripting I'm
207 most familiar with. I tried perl but that didn't go so well. I have on
208 my list to learn python some day, but it's been on my list for awhile,
209 and bash can do way more than a lot of people give it credit for, even if
210 it's not the most efficient choice for the job otherwise.
211
212 > [2] How to opt out of a semantic-desktop?
213 > http://forums.gentoo.org/viewtopic-t-963504.html
214
215 I guess you're more of a forums user than I. If we do the forums, new
216 topic in desktop environment, or unsupported software, or ...? Or
217 continue with the topic above?
218
219 And do we combine the kde and tools subjects in a single topic or one for
220 each?
221
222 What else?
223
224 Back to the list vs forums thing:
225
226 FWIW, I prefer lists as I actually prefer newsgroups, and read my lists
227 via gmane as newsgroups. However, I guess one goes where the audience
228 is, and as I said earlier, web-forums do seem to be more popular, so...
229 But OTOH, this list is already used for kde-sunset and by the gentoo/kde
230 project, so an argument could be made for that too, and people that want
231 to talk about kde-lean bad enough will I guess subscribe... How strong
232 are your forum prefs and do you have any further thoughts/reasons why
233 switching to the forums would be better?
234
235 It's just that... I've been a regular on some lists and/or newsgroups for
236 a decade or more (I've been a regular on the pan lists since 2002,
237 according to gmane, and I've been on some newsgroup or another since I
238 discovered them back in 1997 or so, back on MS with the IE4 previews),
239 but despite the best of intentions, I've never been able to handle a
240 forum for more than a couple months before I burn out on it, so quite
241 apart from the personal preference thing, a real-life consideration is
242 that my own longevity as a project contributor before burnout may well be
243 conditional on what form the project communications take, list or forum,
244 with the latter very possibly leading to much faster burnout.
245
246 Meanwhile, on another aspect of longevity, I expect I'll be making the
247 switch to kde5/frameworks with their more modular design (which I'm
248 SERIOUSLY hoping means keeping semantic-desktop optional, if not, I'll
249 almost certainly switch to something else rather quickly after I find
250 that out, but I'm optimistic given what I've read about it so far)
251 relatively quickly, as I tend to be somewhat ahead of the pack when it
252 comes to migrations, etc.
253
254 (With kde4 I was a bit slower than usual, as it simply wasn't working for
255 me, but I did try it before 4.0, dropping it for a time when it became
256 obvious that wouldn't be working for me at release, and periodically
257 after that, until 4.2 or so, when I force-switched to kde-4.2.5 despite
258 its brokenness after finding out that 3.x was no longer supported
259 upstream despite previous promises, and that as a result, gentoo/kde was
260 going to be dropping kde3 as well, even tho it took them several months
261 longer to actually drop it.)
262
263 And I'm hoping to switch to wayland about the same time as kde5/
264 frameworks, with the X-wayland client providing legacy X support where
265 necessary, tho all that's rather iffy and vague at this point.
266
267 But all that means my personal interest in kde4-lean may be rather short-
268 lived... perhaps to the end of year or early next, tho with kdelibs4 and
269 kde-workspace4 feature-frozen, kde4 itself is planned to continue getting
270 further updates until say mid-year 2014 (or later if they get behind on
271 kde5/frameworks), which means it'll probably remain available in gentoo
272 until end of 2014 or so, at least.
273
274 However, with interest and help from others, it's quite possible my
275 initial patches and tool code can help jumpstart things, and the project
276 will be able to continue without me by then.
277
278 What do you (and anyone else who cares to jump in) think? Is it
279 reasonable to expect the project to be sustainable without me once I
280 decide to move on to kde5/frameworks, or are my active contributions and
281 patching likely to continue to be necessary, such that it may not be
282 worth even starting the (public) project (other than perhaps simply
283 throwing it over the wall and letting people use it as-is while they can)
284 if I'm not willing to commit to saying with it longer than that?
285
286 As I said, you're more experienced in the forums than I. There's
287 certainly some interest there. But is it likely enough to build
288 something that I can reasonably expect to be sustainable without me in a
289 reasonable time, or is it likely that I (and possibly you) will be doing
290 nearly everything myself/ourselves, and once I move on, the whole thing
291 will dry up and blow away? And if it does dry up and blow away when I
292 leave, will it have been worth the trouble for the time it will have been
293 available (hey, it gave people six months they'd have not had otherwise
294 and that's something!), or not?
295
296 I guess it's likely that (given your help anyway) at least the ebuild-
297 patching framework will continue on as a viable tool, quite independent
298 of the kde-lean project where it originated. That's something.
299
300 Of course the other possibility is that kde5/frameworks will continue an
301 optional semantic-desktop, but that contrary to gentoo norms and values,
302 the gentoo/kde project will fail to support that option there as it's now
303 doing with 4.11, in which case kde-lean in some form may continue to be
304 viable into kde5/frameworks... But that's a possibility that remains to
305 be seen, and if it /does/ happen, I'm sure I'll need even more help
306 longer term to keep the kde-lean option viable.
307
308 Finally, it's worth confirming one thing brought up on the forum thread.
309 I don't see any realistic possibility of doing anything further with
310 kdepim in a no-semantic kde. That's an upstream hard-dependency and I
311 don't see anyw way around it, making kdepim totally non-viable for our
312 purposes. Agreed? Given that, I believe it best not to carry kdepim in
313 the kde-lean overlay at all, and to recommend that people use something
314 else. Claws-mail seems the most direct low-dep but still GUI replacement
315 for both kmail and (with the feed plugin) akregator, but of course people
316 can choose thunderbird or something else if they prefer. Meanwhile, we
317 can recommend that those that want to keep kmail or other kdepim
318 components use the semantic-desktop enabled mainline gentoo/kde,
319 instead. Thus they can choose kdepim and semantic-desktop with mainline
320 gentoo/kde, or kde-lean and alternatives to kdepim packages, their choice.
321
322 And one more thing: Short term, is it worth it to post the 4.10.80+
323 patches as I have them either here or to the forum thread linked above,
324 or is it better to wait until we have an overlay to put them in and/or
325 until 4.11.0 is available? Because I see creaker posted his modified
326 kdelibs ebuild, but I think that was still kde 4.10.4. My patches are
327 tested not to pull in the deps here at all (unlike his kdelibs-only
328 ebuild), but they're for 4.10.80+, where the semantic-desktop USE flag is
329 already gone, and thus won't apply cleanly to earlier versions that still
330 have it. Also, while complete for the packages I have installed, I don't
331 have a full kde installed (obviously not kdepim, but beyond that too), so
332 further patches will likely be needed for other packages.
333
334 --
335 Duncan - List replies preferred. No HTML msgs.
336 "Every nonfree program has a lord, a master --
337 and if you use the program, he is your master." Richard Stallman

Replies

Subject Author
[gentoo-desktop] Re: kde-lean TL;DR unless you're going to use it ;) "Steven J. Long" <slong@××××××××××××××××××.uk>