Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
On Fri, 23 Aug 2013 14:27:02 +0100 "Steven J. Long" wrote: > On Sat, Aug 10, 2013: > Tom Wijsman wrote: > > "Steven J. Long" wrote: > > > > > The core system has to be a usable basis to build "everything" > > > from. > > > > I do agree with this except for "shaky"; it is a nice goal to > > pursue... > > > > That still does not make us able to do it or make it a realistic > > goal. > > But it's exactly what the standard Gentoo install supplies, or used > to. So it's very realistic, since it's the basis we've been using for > a decade. You start from something small, which does the described thing; but once you grow to something bigger, you are suddenly no longer able to satisfy that description. In order to continue to grow bigger, you need to cut corners and take decisions; in other words, you can no longer hold on to the prototype that was made but start to need to face the realism that is out there. Just because you can start with something, doesn't mean it is scalable; supporting more comes at its own cost, which may not give enough ROI. > And you are able to do it. At the cost of other things; so, in the whole picture, one can think of it as an unrealistic goal unless someone does want to do all the work without leaving other users that use the software product in the dark. > Losing that capability is nothing more or less than a regression for > a meta-distribution. It is as much a loss as it is a gain; a software product that doesn't deal with bugs because it has to be busy with supporting everything that is out there, is going to leave other regressions behind as well. > > > Design choices have consequences in terms of where manpower can > > > go, as well as in terms of end-user capability and flexibility, > > > especially when one of the "options" has far-reaching implications > > > for the rest of the stack, such that it is a question of "my way > > > or the high way," which seems counter to the idea of choice i > > > hear so much about. > > > > "My way or the high way" is giving good service to just a set of > > users, because you can't listen and support everyone with limited > > resources; as a result it causes alternatives to be created, > > effectively giving choice. > > This is a total non-sequitur, given that we already have choice. You have a choice, but don't have support for it; it is still their choice whether to choose to support you, and when they do, they are giving less support in other places as a result of a cost in time. > Taking it away does not create choice: it merely restricts everyone > until a "hate" fork happens, or some other alternative is provided, > to restore the previous state of affairs. Well, such happenings would introduce a supported choice. > Though to be honest, your argument is more akin to a conceptual > discussion as to "whether an argument could be made" rather than > "what is the best way forward in the long-term for the diverse > user-base." Not very practical, imo. As long as nobody wants to do the work, it remains conceptual; the best way forward is to work with what we are given, until someone gives us what we want or we really want to do the work we want ourselves. > "Giving service to a set of users" is not at all the same as "my way > or the high way." The latter is what happens when you get non-modular > software that tries to do too much, under the banner of "One True > Way" to disguise the awful coupling, however it's dressed up. There are not a lot of products that can give service to everyone; so, people use what they believe is the "One True Way" for them. > The former is what happens when you install say an httpd to serve an > intranet. It doesn't dictate what other pieces of software you can > use for orthogonal purposes (or suddenly expand its feature-base to > include everything else so it isn't orthogonal any more.) When you buy a small row house without a garage or a ramp; you will not be able to park your car in your just bought house. If you try to do it anyway, you will break it. > > This is a natural thing to happen, as everything supporting > > everything does not sound possible at all; it is therefore > > unrealistic. > > What's unrealistic is expecting us to swallow regressions as progress. The opposite is also unrealistic; so, they had to make a design choice. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
On Sat, Aug 10, 2013: Tom Wijsman wrote: > "Steven J. Long" wrote: > > > The core system has to be a usable basis to build "everything" from. > > I do agree with this except for "shaky"; it is a nice goal to pursue... > > That still does not make us able to do it or make it a realistic goal. But it's exactly what the standard Gentoo install supplies, or used to. So it's very realistic, since it's the basis we've been using for a decade. And you are able to do it. Losing that capability is nothing more or less than a regression for a meta-distribution. > > > Making such a design choice isn't a fault. There is no need for > > > blame. > > > > Design choices have consequences in terms of where manpower can go, > > as well as in terms of end-user capability and flexibility, > > especially when one of the "options" has far-reaching implications > > for the rest of the stack, such that it is a question of "my way or > > the high way," which seems counter to the idea of choice i hear so > > much about. > > "My way or the high way" is giving good service to just a set of users, > because you can't listen and support everyone with limited resources; > as a result it causes alternatives to be created, effectively giving > choice. This is a total non-sequitur, given that we already have choice. Taking it away does not create choice: it merely restricts everyone until a "hate" fork happens, or some other alternative is provided, to restore the previous state of affairs. Though to be honest, your argument is more akin to a conceptual discussion as to "whether an argument could be made" rather than "what is the best way forward in the long-term for the diverse user-base." Not very practical, imo. "Giving service to a set of users" is not at all the same as "my way or the high way." The latter is what happens when you get non-modular software that tries to do too much, under the banner of "One True Way" to disguise the awful coupling, however it's dressed up. The former is what happens when you install say an httpd to serve an intranet. It doesn't dictate what other pieces of software you can use for orthogonal purposes (or suddenly expand its feature-base to include everything else so it isn't orthogonal any more.) > This is a natural thing to happen, as everything supporting > everything does not sound possible at all; it is therefore unrealistic. What's unrealistic is expecting us to swallow regressions as progress. > > So it's perfectly reasonable for them to be questioned and criticised. > > Not sure what and whom you mean to refer to by this. "Design choices." Hell, that's one of the main purposes of this list; it's why the GLEP process mentions the list, for example. Sorry for delay, missed this in my inbox. Regards, steveL. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
On Sat, 10 Aug 2013 20:34:58 +0100 "Steven J. Long" wrote: > Tom Wijsman wrote: > > Let's say that I were to develop a system with some other Gentoo > > devs; that doesn't mean we are able to make everything in the tree > > support that system, making it an usable tool for everything is > > unrealistic > > This isn't just "any tool" though: it's the core init-system. Your > reasoning is on shaky ground during this part of your mail, for that > reason. If we were discussing one app against another, or even one DE > against another, it would be a different matter. > > The core system has to be a usable basis to build "everything" from. I do agree with this except for "shaky"; it is a nice goal to pursue... That still does not make us able to do it or make it a realistic goal. > Even if one end-user choice precludes another. Somehow I don't like > the idea of switching from a systemd-stage3 to openrc, whereas the > inverse seems like a viable option. That's a path people can consider to work on in the future, I guess. > > Making such a design choice isn't a fault. There is no need for > > blame. > > Design choices have consequences in terms of where manpower can go, > as well as in terms of end-user capability and flexibility, > especially when one of the "options" has far-reaching implications > for the rest of the stack, such that it is a question of "my way or > the high way," which seems counter to the idea of choice i hear so > much about. "My way or the high way" is giving good service to just a set of users, because you can't listen and support everyone with limited resources; as a result it causes alternatives to be created, effectively giving choice. This is a natural thing to happen, as everything supporting everything does not sound possible at all; it is therefore unrealistic. > It appears to be akin to the argument that freedom means the freedom > to hurt whoever you want without concern. > > So it's perfectly reasonable for them to be questioned and criticised. Not sure what and whom you mean to refer to by this. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
[gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
Tom Wijsman wrote: > Let's say that I were to develop a system with some other Gentoo devs; > that doesn't mean we are able to make everything in the tree support > that system, making it an usable tool for everything is unrealistic This isn't just "any tool" though: it's the core init-system. Your reasoning is on shaky ground during this part of your mail, for that reason. If we were discussing one app against another, or even one DE against another, it would be a different matter. The core system has to be a usable basis to build "everything" from. Even if one end-user choice precludes another. Somehow I don't like the idea of switching from a systemd-stage3 to openrc, whereas the inverse seems like a viable option. > Making such a design choice isn't a fault. There is no need for blame. Design choices have consequences in terms of where manpower can go, as well as in terms of end-user capability and flexibility, especially when one of the "options" has far-reaching implications for the rest of the stack, such that it is a question of "my way or the high way," which seems counter to the idea of choice i hear so much about. It appears to be akin to the argument that freedom means the freedom to hurt whoever you want without concern. So it's perfectly reasonable for them to be questioned and criticised. Please note: I fully support gnome-3.8 stabilising with a hard-requirement on systemd. News just in: software requires another piece of software to work. It's also been obvious for ages that the consensus is to supply unit files where available, be that from upstream or a Gentoo user/developer, so I wish people would stop banging on about it (not you, just in general: it's a dead argument yet it keeps being raised as if that's what the concerns are about.) The rest of us don't really need to worry that much, imo. It's not like the kernel's going away, and we now have a viable to alternative to udev once that gets fully absorbed into the spaghetti-lasagne-fest that is systemd. The stuff we rely on, the simplicity and modularity, always wins out in the end, because it's more efficient and more robust in the long-term, and the wheel turns again, til in a decade there'll be another "amazing innovation" that "changes everything" if you could just see the light/drink the kool-aid. It just doesn't get discussed much, since it's in the background doing all the boring stuff. And has done for decades. regards, igli -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
On Thu, Aug 8, 2013 at 5:45 AM, hasufell wrote: > On 08/08/2013 08:21 AM, Duncan wrote: >> >> None-the-less, I do understand the problem of a gentoo project supporting >> an option no devs on the project are actually interested in running. > > I do not. If that is the policy, then the project is doing something wrong. > Feel free to join it and do something right then. :) I don't know what it was costing them to support USE=-semantic-desktop. Their logic for no longer providing the option was that the effects of the option were now configurable in the control panel. Granted, you'd still end up pulling in the deps, but they wouldn't actually do anything. I like being able to use kdepim (or would if it didn't prompt me to re-authenticate with Google two factor on every login), so this is an improvement. I could see why others might want the flag to remain. If it works and somebody is willing to proxy-maintain the necessary elements to support it, they should be allowed to do so unless it causes some other problem. Rich
Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
On 08/08/2013 08:21 AM, Duncan wrote: > > None-the-less, I do understand the problem of a gentoo project supporting > an option no devs on the project are actually interested in running. I do not. If that is the policy, then the project is doing something wrong.
[gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
Duncan posted on Thu, 08 Aug 2013 08:27:58 + as excerpted: > Daniel Campbell posted on Thu, 08 Aug 2013 01:26:47 -0500 as excerpted: > >> [Duncan wrote...] Ooopps! That too... WAS intended to be sent privately. I goofed! Sorry everyone! (Note to self, change the followup BEFORE you start composing the reply, so you don't forget before hitting the send button! =:^( -- 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
[gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
Daniel Campbell posted on Thu, 08 Aug 2013 01:26:47 -0500 as excerpted: > [Duncan wrote...] >> Gentoo/gnome is simply working with what upstream gnome gives them, >> which for gentoo/gnome users now means a choice between gnome with >> systemd and if no systemd, no gnome either. Upstream decision that >> gentoo/gnome is dealing with too. >> >> ... >> >> So as I said, gentoo/kde-ers would be so lucky, if the gentoo/kde >> project took the same position gentoo/gnome's taking here, that they >> support what upstream offers, that gentoo/gnome's only forcing systemd >> because upstream gnome's forcing it. Were that the case, >> semantic-desktop wouldn't be forced by gentoo/kde in kde 4.11, where >> upstream still offers the same options they did in 4.10, where >> gentoo/kde offered the option as well. >> > Wow, that really sucks. I'm not posting this to the ML since I have > nothing to offer to their discussion. The best of intents... you did. =:^\ > All this mess with GNOME and KDE > makes me happy to run vanilla X with Fluxbox, though. :P Which options > have you considered, if Gentoo/KDE doesn't re-enable the option to > disable semantic desktop? [This is probably a rather longer reply than you expected, but eh... it helps me order my thoughts and plans by putting them into words, as well...] For now, I'm carrying the necessary patches (generated by examining the diffs between the ebuilds with and without that support, updating as needed) myself. This is in fact how I can state with such certainty that upstream still provides the required options -- I'm still using them! But I started a thread on the gentoo-desktop list (which is where the kde- sunset people gathered as well as where gentoo/kde announces meetings, etc) asking if anyone else were interested in helping, with the idea of doing something like the user maintained kde-sunset overlay. That generated a number of hits, and there's a thread on the forums discussing the topic (and linking to the list thread) as well, so I'm definitely not the only one unhappy with the current situation. Tho I've let that sit for a couple weeks as "real life" got in the way, unfortunately. Meanwhile, if all goes well, the effort should be reasonably short term, as upstream kde has already announced that for kde5 they're going far more modularized, splitting off most packages to have independent releases no longer necessarily synced to the kde core release cycle and versioning, and indeed, for kde5, they're calling that core kde-frameworks-5 -- which then itself becomes a much smaller kde5, as all the newly independent packages WILL have their own release cycle and versioning. Given the further modularization for kde5/frameworks as the primary declared and apparently well under way goal (an early preview release of this core/framework is apparently already available, tho I've not tried it) and no indications to the contrary, it seems unlikely that they'd actually DE-modularize the semantic-desktop components, making them LESS optional for frameworks and the basic desktop in the supposedly MORE modularized kde5/frameworks than in current kde4, and in fact, kde's plasma desktop itself has evolved to target (non-kde) mobile deployment as its own "mobile-top" in the mean time too, so it really doesn't seem that plasma2's likely to force a dependency that even on the desktop takes enough resources to cause people to care strongly enough about getting it off their systems that they'll go to extreme lengths to do it. So I'm /reasonably/ optimistic about kde5/frameworks not requiring semantic-desktop at the global level. Which of course makes gentoo/kde's choice so late in the game (with 4.11 being declared the last 4-series feature release for many kde4 apps including the plasma-desktop itself) even *MORE* galling than it'd otherwise be! Never-the-less, realistically, I don't see myself continuing "forever" with these patches, particularly if the "kde-slim" overlay idea doesn't pan out... Should that happen, and should I be wrong about kde5/frameworks not hard- requiring semantic-desktop (or should gentoo/kde continue to hard-enable it in kde5/frameworks despite upstream's support for the option)... My current plan is in that worst-case to switch, with my "investigate- further-short-list" currently including: * The new and still evolving razor-qt/lxde-qt http://wiki.lxde.org/en/LXDE-Qt * enlightenment * Possibly something gtk-related like xfce, given how far toward the gtk side I've tipped since kde4. But currently that's all gtk2, and with gtk2's own future in doubt and gtk3's close ties to the our-way-or-the- highway gnome, so that even formerly gtk-based desktops like lxde are turning qt, for all I can see that'd be a jump from the frying pan into the fire, so I'd have to see some potential resolution to the gtk2/gtk3 issue, before considering that for anything longer term. (I've actually been wondering what
KDE/semantic-desktop, was: Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
Am Donnerstag, 8. August 2013, 08:21:47 schrieb Duncan: > ... > > [Those uninterested in gentoo/kde can stop reading here, as the rest of > the post is a complaint about that project not taking the same position.] > > Gentoo/kde users would be so lucky! > > As a gentoo/kde-er, I *WISH* the gentoo/kde team was as similarly willing > to continue support for the options kde upstream *ARE* still providing -- > kde4 with the semantic-desktop options turned off. Let me quote a user comment from my blog [who was in the beginning very much concerned about this decision as well]: "I decided it might be wise to rebuild +semantic-desktop globally, to see for myself what would actually happen. After 8 hours of compiling (Atom N270) the answer is about 10 additional megs of ram at idle and about 2 extra seconds to boot. There is no performance penalty to load gwenview or dolphin. kdelibs took an additional 10 minutes to compile (2h 15 vs 2h 5); the flag system wide should not increase my compile times by more than a percentage point or two. Given that the hit is extremely minimal: I do apologise for getting prematurely butthurt, and I welcome our new semantic overlords." It's simply a matter of priorities. If the resulting damage is that minimal, it is not worth the effort. (I mean, it's not as if you'd have to switch to a totally different init system or such. :) -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
On 08/08/2013 01:21 AM, Duncan wrote: > Alex Alexander posted on Thu, 08 Aug 2013 05:51:38 +0300 as excerpted: > >> On Thu, Aug 8, 2013 at 2:49 AM, Patrick Lauer wrote: >> >>> On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote: On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote: > > Gnome Herd decided to target stablilization of 3.8 [1] which > requires systemd. > > What are the reasons to stable 3.8 and not 3.6, a version w/o this > restriction, enabling all non systemd users to profit from this > eye-candy as well. To stabilize gnome-3.6, we would need [people willing to do it]. We do not have such people on the gnome team. >>> Seeing the noise in #gentoo from people getting whacked in the kidney >>> by the systemd sidegrade ... that's a very optimistic decision. >>> >>> It'll cause lots of pain for users that suddenly can't start lvm >>> properly and other nasty landmines > >>> I hope you understand that some of us will be very rude and just >>> suggest to unmerge gnome on all support requests as it now moves >>> outside our support range ... >>> >> Although I understand your frustration, I don't see any other options >> for the Gentoo gnome team. People who don't like this should take their >> complaints upstream. > > That reads to me like resigned acceptance. > > Gentoo/gnome is simply working with what upstream gnome gives them, which > for gentoo/gnome users now means a choice between gnome with systemd and > if no systemd, no gnome either. Upstream decision that gentoo/gnome is > dealing with too. > > ... > > [Those uninterested in gentoo/kde can stop reading here, as the rest of > the post is a complaint about that project not taking the same position.] > > Gentoo/kde users would be so lucky! > > As a gentoo/kde-er, I *WISH* the gentoo/kde team was as similarly willing > to continue support for the options kde upstream *ARE* still providing -- > kde4 with the semantic-desktop options turned off. Yes, this does mean > doing without kdepim, but that has been the case for several versions, no > upstream change there for 4.11, at least not for kde's base packages as > necessary to run a kde desktop, yet gentoo carried support for building > kde without semantic-desktop in 4.10, and doesn't in 4.11. > > Meanwhile, while the same build-time options that worked in 4.10 still > work in 4.11 (I know, as I put a lot of work into patching the ebuilds > here when gentoo/kde removed the options despite upstream continuing to > have them), the gentoo/kde project has decided to force the semantic- > desktop option ON for gentooers even where upstream continues to provide > the option to turn it off! > > > None-the-less, I do understand the problem of a gentoo project supporting > an option no devs on the project are actually interested in running. > Testing would be left to users, and quality would suffer a bit as a > result, but I know for a fact that there's users out there DOING that > testing, even with the additional cost of having to maintain ebuild > patches themselves to do it, because I'm one of them! Further, I'm > running 4.11.49. live-branch and was running the betas before the > branch from trunk, so there's at least one user actually doing that > testing early enough to catch a good share of that feature's problems > before they get anywhere close to ~arch, let alone stable. > > Despite, or perhaps /because/ of, all the previous pain kde upstream has > caused its users with the 4.x bump (which unlike the 4.10/4.11 bump was > at LEAST a major version bump) and with kdepim's switch to akonadi > mid-4.x (which unfortunately was NOT a major version bump), this time > there's no indication of upstream kde changing semantic-desktop horses > mid-stream and mid-major-version and forcing it on like that; it's > gentoo/kde that's doing it, pure and simple. > > And I've already posted that regardless of what upstream kde or gentoo/kde > does, after all the trouble I went thru to rid my system of semantic- > desktop earlier in the kde4 series, I'm not ABOUT to enable it again now, > yes indeed, even if that means I unmerge the kde desktop entirely and > switch to something else -- which after all I've already done for major > portions of kde, including switching kmail->claws-mail when kdepim > unfortunately jumped the shark mid-major-version. > > > So as I said, gentoo/kde-ers would be so lucky, if the gentoo/kde project > took the same position gentoo/gnome's taking here, that they support what > upstream offers, that gentoo/gnome's only forcing systemd because > upstream gnome's forcing it. Were that the case, semantic-desktop > wouldn't be forced by gentoo/kde in kde 4.11, where upstream still offers > the same options they did in 4.10, where gentoo/kde offered the option as > well. > > Meanwhile, I guess I know what the kde-sunset users felt like now... > except in that case as well as
[gentoo-dev] Re: Gnome Stabilization 3.6 or 3.8
Alex Alexander posted on Thu, 08 Aug 2013 05:51:38 +0300 as excerpted: > On Thu, Aug 8, 2013 at 2:49 AM, Patrick Lauer wrote: > >> On 08/07/2013 09:14 PM, Alexandre Rostovtsev wrote: >> > On Wed, 2013-08-07 at 14:45 +0200, Michael Weber wrote: >> >> >> >> Gnome Herd decided to target stablilization of 3.8 [1] which >> >> requires systemd. >> >> >> >> What are the reasons to stable 3.8 and not 3.6, a version w/o this >> >> restriction, enabling all non systemd users to profit from this >> >> eye-candy as well. >> > >> > To stabilize gnome-3.6, we would need [people willing to do it]. >> > We do not have such people on the gnome team. >> > >> Seeing the noise in #gentoo from people getting whacked in the kidney >> by the systemd sidegrade ... that's a very optimistic decision. >> >> It'll cause lots of pain for users that suddenly can't start lvm >> properly and other nasty landmines >> I hope you understand that some of us will be very rude and just >> suggest to unmerge gnome on all support requests as it now moves >> outside our support range ... >> > Although I understand your frustration, I don't see any other options > for the Gentoo gnome team. People who don't like this should take their > complaints upstream. That reads to me like resigned acceptance. Gentoo/gnome is simply working with what upstream gnome gives them, which for gentoo/gnome users now means a choice between gnome with systemd and if no systemd, no gnome either. Upstream decision that gentoo/gnome is dealing with too. ... [Those uninterested in gentoo/kde can stop reading here, as the rest of the post is a complaint about that project not taking the same position.] Gentoo/kde users would be so lucky! As a gentoo/kde-er, I *WISH* the gentoo/kde team was as similarly willing to continue support for the options kde upstream *ARE* still providing -- kde4 with the semantic-desktop options turned off. Yes, this does mean doing without kdepim, but that has been the case for several versions, no upstream change there for 4.11, at least not for kde's base packages as necessary to run a kde desktop, yet gentoo carried support for building kde without semantic-desktop in 4.10, and doesn't in 4.11. Meanwhile, while the same build-time options that worked in 4.10 still work in 4.11 (I know, as I put a lot of work into patching the ebuilds here when gentoo/kde removed the options despite upstream continuing to have them), the gentoo/kde project has decided to force the semantic- desktop option ON for gentooers even where upstream continues to provide the option to turn it off! None-the-less, I do understand the problem of a gentoo project supporting an option no devs on the project are actually interested in running. Testing would be left to users, and quality would suffer a bit as a result, but I know for a fact that there's users out there DOING that testing, even with the additional cost of having to maintain ebuild patches themselves to do it, because I'm one of them! Further, I'm running 4.11.49. live-branch and was running the betas before the branch from trunk, so there's at least one user actually doing that testing early enough to catch a good share of that feature's problems before they get anywhere close to ~arch, let alone stable. Despite, or perhaps /because/ of, all the previous pain kde upstream has caused its users with the 4.x bump (which unlike the 4.10/4.11 bump was at LEAST a major version bump) and with kdepim's switch to akonadi mid-4.x (which unfortunately was NOT a major version bump), this time there's no indication of upstream kde changing semantic-desktop horses mid-stream and mid-major-version and forcing it on like that; it's gentoo/kde that's doing it, pure and simple. And I've already posted that regardless of what upstream kde or gentoo/kde does, after all the trouble I went thru to rid my system of semantic- desktop earlier in the kde4 series, I'm not ABOUT to enable it again now, yes indeed, even if that means I unmerge the kde desktop entirely and switch to something else -- which after all I've already done for major portions of kde, including switching kmail->claws-mail when kdepim unfortunately jumped the shark mid-major-version. So as I said, gentoo/kde-ers would be so lucky, if the gentoo/kde project took the same position gentoo/gnome's taking here, that they support what upstream offers, that gentoo/gnome's only forcing systemd because upstream gnome's forcing it. Were that the case, semantic-desktop wouldn't be forced by gentoo/kde in kde 4.11, where upstream still offers the same options they did in 4.10, where gentoo/kde offered the option as well. Meanwhile, I guess I know what the kde-sunset users felt like now... except in that case as well as the gentoo/gnome case but unlike this one, upstream WAS dropping support, and the gentoo project was simply following upstream... -- Duncan - List replies preferred. No HTML msgs. "Every non
