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 |