[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-desktop
Subject:    [gentoo-desktop] Re: kde-lean ;)
From:       Duncan <1i5t5.duncan () cox ! net>
Date:       2013-07-11 16:45:17
Message-ID: pan$6fee4$e239c834$7406f263$c98f885d () cox ! net
[Download RAW message or body]

Steven J. Long posted on Thu, 11 Jul 2013 13:59:32 +0100 as excerpted:

> <Resend after subscribe>
> Duncan wrote:
>> 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]
>>
>> 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.
> 
> I *totally* concur. After finally getting rid of KMail, it took me 9
> months to work out and feel comfortable with mutt[1], and then it was
> much less of a step to get rid of nubkit, as well as semantic-craptop.
> 
> Finally, at 4.9 my KDE has come back to me, and feels as slick as 3.5
> :-)

It was kde 4.7 for me, but I definitely know the feeling. There's more 
that could be said on that theme, but I guess for anyone interested in 
this thread, it's preaching to the choir.  Suffice it to say that none of 
us greeted that gentoo/kde announcement with rejoicing, to say the least, 
but... (vvv)

> That's progress for ya.. ;p

(^^^) ... =:^(

>> 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/.
> 
> Hmm that's quite interesting. Not something I'd personally want in the
> tree, but definitely of interest to more advanced admins, as opposed to
> end-users.

Of course, as I guess you'll recall (you've been around long enough I 
think) that's what was originally said about epatch_user as well...

> (Yeah, we're all admins. Still, I don't administer a large network, and
> I don't call myself a sys-admin. I just appreciate good infra.)

I definitely call myself a sysadmin.  It's my stated opinion that if 
people were to take the job of administering their own systems as 
seriously as a sysadmin does or should do (and I definitely do), then 
we'd not have the problem with malware that we do, as there'd always be 
insecure systems, but like a well immunized population, the immunity 
level of the population as a whole would mean the number of infectible 
hosts would be below that required for viable propagation, and the 
infections simply wouldn't spread as there wouldn't be enough vulnerable 
systems within reach for them to spread to.

Administrating a computer system is a serious job, and the more people 
that consider it so, the less danger everyone, both those that treat the 
job seriously and those who don't, are in.

So yes, I'm definitely a sysadmin, even if it's only for a couple 
systems.  And yes, I take that job seriously, even if I'm not paid for it 
because they're my own systems, administered as a hobby.


Meanwhile, before "ebuild_patch_user" gets to the point that it's 
acceptable in mainline (if it /ever/ gets to the point that it's 
acceptable in mainline), just as epatch_user, time and many rounds of 
revision (and an appropriate level of verbosity saying an ebuild was 
modified in emerge --info <pkg>, for posting with bugs) will be needed.

>> 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.
> 
> Have to say I think I'd prefer this as a semi-automatically generated
> overlay.  ie apply the patches, and if they work, let the maintainer
> confirm after testing.

If the target audience is to include the less experienced, as you're 
hinting at, then ultimately I must agree.

>> 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.
> 
> Indeed. You shouldn't be doing this alone, over the longer-term: it'll
> just burn you out.

So we agree. =:^)

>> 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?
> 
> Hell yeah :-)[2] You picked an odd forum for it though: I only found out
> about this because Dominique posted to pro-audio list.

I picked this list/forum for a couple (related) reasons, in addition to 
convenience (I was already subscribed).

1) It's the coordinating list for kde-sunset, and this seemed a 
reasonably similar project, so using the same list seemed appropriate.

2) This list is also where the gentoo/kde project posts meeting 
announcements and sometimes summaries, etc.

Together those make this list more or less the all-things-kde list (not 
excluding the more general desktop bit, but particularly for those 
interested in kde...), and it seemed to me to make this the logical place 
to post, certainly for an initial feeler.

>> 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
> 
> Yes, as above. I much prefer the traceability of an overlay with
> conventional ebuilds in it. If we're going to do this, let's do it
> right.

OK, barring any strong feeling posted to the contrary... WORKSFORME. =:^)

> Yes, the tools should be available in their own right.
> 
> Tho that was an awfully long-winded way of saying "Ebuild-patch tools
> could well be of wider interest." ;)

I blame all those "minimum 2 pages" (replacing 2 with a larger number as 
I advanced) assignments in school, when two paragraphs totaling half a 
page would have well sufficed.  All those years of schooling forcing 
rediculous verbosity... and I hit "real life" and everybody's saying 
tl;dr!  Talk about schools teaching the wrong thing!

>> 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.
> 
> That sounds ideal, but why not just have two overlays? One for
> ebuild-patch which others can use and collaborate around, and one
> conventional kde-lean for people who want the end-product.

kde-lean definitely beats kde-nosemantic, my working title.

As for ebuild-patch, an overlay just for it?  What about setting up a git 
repo somewhere (github's popular, but not open source...) and putting the 
ebuild for it, presumably using git2.eclass for a live-9999 version, in 
the sunrise overlay?  Once it gets mature enough to tag, if we don't want 
to bother with a tarball, a versioned ebuild can still use the git 
infrastructure, and simply checkout a specific tag.

> After all, ebuild-patch tools are strictly for maintainers, and people
> who want to experiment on their system. The output ebuilds have an
> orthogonal use.

Agreed.

> I'd ask that we collaborate on the forums[2] about this: things can move
> much quicker there, and you get general encouragement and lots of bug
> feedback, as well as others to help.

I've actually seen lists/newsgroups move in very close to real-time -- as 
close as I generally care to get (I don't do IRC as I like a bit more 
time to compose my posts).

But, web-forums do seem to be more popular, and I guess I could dust off 
my old forum login or create a new one...

> creaker patched kdelibs, as you'll see, already, and he's interested in
> working on the overlay ("Without overlay it may be boring to do the
> things I did before on every update.") So between the two of you, and as
> others get involved, I'm sure it can be done. As you said, KDE-4 is
> practically EOL, given that more developer focus is on 5.
> 
> I can get the overlays, git and trac setup, same as we did for hardened
> a few years ago, if that helps.

That would be useful.

Person to person, let me also say I'm absolutely thrilled to have you 
helping.  I didn't know you were a kde-er so thought it a bit much to 
hope for, but I definitely consider your bash skills well above mine 
(you're the name that comes to mind when the words "bash coder" get 
used), and have little doubt that you'll be able to beat my poor hacks 
that work on my system but that I wouldn't consider secure or robust 
enough for general purpose use into much better general-purpose shape, 
far faster/better than I could.

And I expect quite apart from improving the tools themselves, I'll learn 
quite a lot from the process, and my next project will be rather higher 
(dare I say professional?) quality early code as a result.  I certainly 
can't argue with that! =:^)

Of course there's other than shell/bash, but that's the scripting I'm 
most familiar with.  I tried perl but that didn't go so well.  I have on 
my list to learn python some day, but it's been on my list for awhile, 
and bash can do way more than a lot of people give it credit for, even if 
it's not the most efficient choice for the job otherwise.

> [2] How to opt out of a semantic-desktop?
>     http://forums.gentoo.org/viewtopic-t-963504.html

I guess you're more of a forums user than I.  If we do the forums, new 
topic in desktop environment, or unsupported software, or ...?  Or 
continue with the topic above?

And do we combine the kde and tools subjects in a single topic or one for 
each?

What else?

Back to the list vs forums thing:

FWIW, I prefer lists as I actually prefer newsgroups, and read my lists 
via gmane as newsgroups.  However, I guess one goes where the audience 
is, and as I said earlier, web-forums do seem to be more popular, so...  
But OTOH, this list is already used for kde-sunset and by the gentoo/kde 
project, so an argument could be made for that too, and people that want 
to talk about kde-lean bad enough will I guess subscribe...  How strong 
are your forum prefs and do you have any further thoughts/reasons why 
switching to the forums would be better?

It's just that... I've been a regular on some lists and/or newsgroups for 
a decade or more (I've been a regular on the pan lists since 2002, 
according to gmane, and I've been on some newsgroup or another since I 
discovered them back in 1997 or so, back on MS with the IE4 previews), 
but despite the best of intentions, I've never been able to handle a 
forum for more than a couple months before I burn out on it, so quite 
apart from the personal preference thing, a real-life consideration is 
that my own longevity as a project contributor before burnout may well be 
conditional on what form the project communications take, list or forum, 
with the latter very possibly leading to much faster burnout.

Meanwhile, on another aspect of longevity, I expect I'll be making the 
switch to kde5/frameworks with their more modular design (which I'm 
SERIOUSLY hoping means keeping semantic-desktop optional, if not, I'll 
almost certainly switch to something else rather quickly after I find 
that out, but I'm optimistic given what I've read about it so far) 
relatively quickly, as I tend to be somewhat ahead of the pack when it 
comes to migrations, etc.

(With kde4 I was a bit slower than usual, as it simply wasn't working for 
me, but I did try it before 4.0, dropping it for a time when it became 
obvious that wouldn't be working for me at release, and periodically 
after that, until 4.2 or so, when I force-switched to kde-4.2.5 despite 
its brokenness after finding out that 3.x was no longer supported 
upstream despite previous promises, and that as a result, gentoo/kde was 
going to be dropping kde3 as well, even tho it took them several months 
longer to actually drop it.)

And I'm hoping to switch to wayland about the same time as kde5/
frameworks, with the X-wayland client providing legacy X support where 
necessary, tho all that's rather iffy and vague at this point.

But all that means my personal interest in kde4-lean may be rather short-
lived... perhaps to the end of year or early next, tho with kdelibs4 and 
kde-workspace4 feature-frozen, kde4 itself is planned to continue getting 
further updates until say mid-year 2014 (or later if they get behind on 
kde5/frameworks), which means it'll probably remain available in gentoo 
until end of 2014 or so, at least.

However, with interest and help from others, it's quite possible my 
initial patches and tool code can help jumpstart things, and the project 
will be able to continue without me by then.

What do you (and anyone else who cares to jump in) think?  Is it 
reasonable to expect the project to be sustainable without me once I 
decide to move on to kde5/frameworks, or are my active contributions and 
patching likely to continue to be necessary, such that it may not be 
worth even starting the (public) project (other than perhaps simply 
throwing it over the wall and letting people use it as-is while they can) 
if I'm not willing to commit to saying with it longer than that?

As I said, you're more experienced in the forums than I.  There's 
certainly some interest there.  But is it likely enough to build 
something that I can reasonably expect to be sustainable without me in a 
reasonable time, or is it likely that I (and possibly you) will be doing 
nearly everything myself/ourselves, and once I move on, the whole thing 
will dry up and blow away?  And if it does dry up and blow away when I 
leave, will it have been worth the trouble for the time it will have been 
available (hey, it gave people six months they'd have not had otherwise 
and that's something!), or not?

I guess it's likely that (given your help anyway) at least the ebuild-
patching framework will continue on as a viable tool, quite independent 
of the kde-lean project where it originated.  That's something.

Of course the other possibility is that kde5/frameworks will continue an 
optional semantic-desktop, but that contrary to gentoo norms and values, 
the gentoo/kde project will fail to support that option there as it's now 
doing with 4.11, in which case kde-lean in some form may continue to be 
viable into kde5/frameworks...  But that's a possibility that remains to 
be seen, and if it /does/ happen, I'm sure I'll need even more help 
longer term to keep the kde-lean option viable.

Finally, it's worth confirming one thing brought up on the forum thread.  
I don't see any realistic possibility of doing anything further with 
kdepim in a no-semantic kde.  That's an upstream hard-dependency and I 
don't see anyw way around it, making kdepim totally non-viable for our 
purposes.  Agreed?  Given that, I believe it best not to carry kdepim in 
the kde-lean overlay at all, and to recommend that people use something 
else.  Claws-mail seems the most direct low-dep but still GUI replacement 
for both kmail and (with the feed plugin) akregator, but of course people 
can choose thunderbird or something else if they prefer.  Meanwhile, we 
can recommend that those that want to keep kmail or other kdepim 
components use the semantic-desktop enabled mainline gentoo/kde, 
instead.  Thus they can choose kdepim and semantic-desktop with mainline 
gentoo/kde, or kde-lean and alternatives to kdepim packages, their choice.

And one more thing:  Short term, is it worth it to post the 4.10.80+ 
patches as I have them either here or to the forum thread linked above, 
or is it better to wait until we have an overlay to put them in and/or 
until 4.11.0 is available?  Because I see creaker posted his modified 
kdelibs ebuild, but I think that was still kde 4.10.4.  My patches are 
tested not to pull in the deps here at all (unlike his kdelibs-only 
ebuild), but they're for 4.10.80+, where the semantic-desktop USE flag is 
already gone, and thus won't apply cleanly to earlier versions that still 
have it.  Also, while complete for the packages I have installed, I don't 
have a full kde installed (obviously not kdepim, but beyond that too), so 
further patches will likely be needed for other packages.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


[prev in list] [next in list] [prev in thread] [next in thread]