Gentoo Archives: gentoo-desktop

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-desktop@l.g.o
Subject: [gentoo-desktop] Re: more kde-sunset upgrade notes
Date: Fri, 15 Apr 2011 03:55:30
Message-Id: pan.2011.04.15.03.53.23@cox.net
In Reply to: [gentoo-desktop] more kde-sunset upgrade notes by Brent Busby
1 Brent Busby posted on Thu, 14 Apr 2011 14:20:47 -0500 as excerpted:
2
3 > Recently, Gentoo decided to phase out Hal completely. Hal has been
4 > deprecated for some time, but now that pretty much all software that's
5 > officially supported from Gentoo's main package pool has been migrated
6 > to use Udev-based mechanisms, Gentoo decided to pull the plug on Hal.
7 > (Watching 2001 for the nth time might have caused them some anxiety
8 > about keeping Hal around any longer too...) Currently, Hal is still in
9 > Portage, but probably won't be much longer. I think someone mentioned
10 > pulling it into the kde-sunset overlay if it becomes necessary for KDE's
11 > sake.
12
13 Interesting post. I appreciate your thoughts, as kde4 (my desktop
14 environment of choice, tho at least I don't have your complications of
15 others as I don't have them installed, nor of *DM, since I strongly prefer
16 logging in at the CLI and running startx to start kde as the user I'm
17 logged in as, from there) uses some of the same tools gnome does, and as
18 it switched away from hal to udev with kde 4.6, as well. The fact that an
19 fstab listing is incompatible with automounting is especially frustrating,
20 altho I prefer much more limited automounting that some, so it's not as
21 bad here as it can be for others.
22
23 But the reason I'm replying has to do with the above quoted bit.
24
25 FWIW, hal will apparently remain around in portage for a bit longer.
26
27 According to a recent post on the dev list, the gentoo/kde project had
28 intended to try to stabilize kde 4.6.2, thus eliminating the hal
29 dependency for stable kde4, clearing the way for its removal from portage.
30
31 But, spanner in the sprockets! That plan doesn't appear to be viable, and
32 while I've not seen anything official from the gentoo/kde folks indicating
33 this, my own experience with 4.6.2 now has me questioning whether any of
34 the 4.6s will be stabilization material. It may well be kde 4.7
35 (presumably at least 4.7.1, with 4.7.0 due for August release and 4.7.1
36 due a month later, with a month for standard Gentoo stabilization... that
37 could EASILY mean October or later for a stable non-hal kde4). Tho it's
38 still possible a later 4.6 will get things together enough to be
39 stabilized, just looking less likely, now.
40
41 Again from that recent gentoo/kde post to the dev list, they had planned
42 on stabilizing a kde 4.6 release. But 4.6.0 was a .0 feature release and
43 thus brought with it a few new bugs, as first-feature releases tend to
44 do. As such, it wasn't really stabilization material, but that was
45 expected.
46
47 Here's where that spanner enters the sprockets, however. Still from that
48 post (tho the spanner analogy is mine), KDE upstream is in the midst of
49 converting from their former svn repo to git, one sub-project at a time,
50 and the process has evidently not been particularly smooth. While the
51 monthly micro-releases (4.6.x) are intended to be bugfix releases on the
52 semi-annual feature minors (4.x), and arguably until 4.6 had been just
53 that, 4.6.1 was a notable regression from 4.6.0, due to confusion from the
54 svn -> git transition, with the wrong head pulled in a number of cases,
55 resulting in code being pulled into the release tarballs that wasn't ready
56 nor intended in that form for them.
57
58 That post was a few days prior to the 4.6.2 release and linked to the kde
59 release list archive discussion of the coming 4.6.2 release, where they
60 were trying to coordinate in an effort to prevent the same sort of issue
61 happening for 4.6.2.
62
63 Meanwhile, 4.6.2 has actually been released. Of course this is now beyond
64 that post, so it's my evaluation from here. If 4.6.1 was a bit of a
65 regression, as from that post it evidently was, for me it was fine. NOT
66 SO 4.6.2! It has a couple nasty regressions that affect me personally,
67 with others affecting other folks, some of which are posting to the kde
68 user lists I follow -- WAY more than they did for the 4.6.1 upgrade.
69 Based both on posts to the kde lists and my own experience, 4.6.2 is
70 anything BUT a stable candidate!
71
72 Given that and in the context of the previous post to gentoo-dev from the
73 gentoo/kde folks, it's going to be some time before a non-hal kde4
74 stabilizes, meaning it's going to be some time before hal can be pulled
75 from the main tree, however much it's disrupting nicely laid plans to lay
76 it to rest.
77
78 (I know I won't be missing hal! One fight with obtuse *.fdi format config
79 files was one too many! I'm on 4.6 and no longer have hal to deal with,
80 GOOD RIDDANCE! Despite the problems, I wouldn't consider going back to
81 it. I've considered reverting to 4.6.0 which was fine at least here, but
82 don't intent to revert further back and have hal to worry about again as a
83 result.)
84
85 What's worse, until 4.6, every kde4 release, feature or bugfix, was
86 arguably better, often MUCH better, than the one before. With 4.6, that's
87 been turned on its head, and while 4.6.1 was arguably an exception, 4.6.2
88 is looking WAY too much like a trend! Yes, we know at least one of the
89 reasons, the continuing upstream svn -> git migration. But it's still a
90 nasty problem and a reversal of the previous very nice trend.
91
92 Given the serious problems with 4.6.1 and now 4.6.2, I'm not sure what'll
93 happen for the remaining monthly 4.6.x releases, 4.6.3 thru 4.6.5. It's
94 looking quite possible now that 4.6.0 will remain the best of the 4.6
95 series and even if they fix the problems with 4.6.1 and 4.6.2, nothing in
96 the 4.6 series will reach stabilization level, as they continue to migrate
97 more bits of kde over and get used to git.
98
99 That would leave 4.7 as the next possibility, tho /maybe/ they can work
100 things out by 4.6.5. If it's 4.7, and the usual 4.7.0 feature release is
101 as usual not considered a stabilization candidate, that means 4.7.1 or
102 later, which as I said above, means October at the earliest.
103
104 Meanwhile, the 4.4 series stable they have now is looking rather long in
105 the tooth. It's quite dated from upstream's perspective, and from my own
106 personal experience, 4.5.4 or so (4.5.0 for me personally, but there were
107 some significant graphics bugs only fixed in 4.5.3 or 4.5.4, that were bad
108 for many users) was the first version I would have considered a proper
109 upgrade from the later 3.5 series. Since 4.4 is previous to that, it
110 should be obvious that I consider Gentoo's current stable 4.4.x a
111 substandard experience, and that I believe a later 4.5 should have been
112 stabilized.
113
114 But, 4.5 is still hal-dependent, so it makes little or no sense to try to
115 stabilize it now, when they're trying to dump hal.
116
117 The other /possible/ alternative would be taking 4.6.0, cherry-picking
118 specific patches from the later 4.6 series to apply on top, and
119 stabilizing that, probably still calling it 4.6.0, but carrying more
120 patches on top than Gentoo traditionally does, altho they /do/ happen to
121 have been applied upstream. If kde were already fully switched to git,
122 that'd be a rather easy process indeed, since git has been specifically
123 designed to allow this sort of cherry-picking, and indeed, has a command
124 called cherry-pick designed to implement it.
125
126 Unfortunately, the conversion svn -> git makes this a challenging option
127 as well, tho if I were on the gentoo/kde project it's something I'd
128 certainly be examining. It's a bad option, certainly, but that doesn't
129 mean it can't still be the best among many bad options. (Hmm, English
130 gets awkward with that many negatives in a sentence! Does that say what I
131 intended it to say?)
132
133 So I don't know what's going to happen. But whatever it might be, due to
134 all these kde 4.6 issues, hal looks to be safe in the tree for a /few/
135 more months, yet. If 4.6.1 wasn't considered stabilization material, it
136 would seem clear to me at least, that 4.6.2 is even worse, so whatever
137 they decide to do, hal has to stick around until it's finished and the
138 latest gentoo/stable kde is no longer hal dependent. Whatever it is they
139 do, it's going to take some time.
140
141 --
142 Duncan - List replies preferred. No HTML msgs.
143 "Every nonfree program has a lord, a master --
144 and if you use the program, he is your master." Richard Stallman

Replies