| Summary: | [Tracker] Removal of sys-apps/hal | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Samuli Suominen (RETIRED) <ssuominen> |
| Component: | Current packages | Assignee: | Freedesktop bugs <freedesktop-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | aballier, axiator, bfx81, Dessa, didier-bugzillagentoo, esigra, junghans, kjackie, mattst88, nelchael, nikoli, polynomial-c, tdalman, write2David, z23 |
| Priority: | High | Keywords: | Tracker |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | https://wiki.ubuntu.com/Halsectomy | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | 299219, 303701, 309759, 311059, 311093, 311095, 313391, 313393, 313395, 313397, 313399, 313423, 313425, 313427, 313429, 313431, 313433, 316383, 316475, 318347, 325467, 339032, 344193, 344313, 349048, 349050, 349053, 349523, 349724, 349762, 350516, 352856, 353839, 355077, 355165, 358935, 358937, 360119, 360123, 360739, 362847, 363789 | ||
| Bug Blocks: | 168033, 182860, 260409, 262981, 267170, 267928, 273111, 281746, 286046, 288206, 292823, 294939, 296423 | ||
|
Description
Samuli Suominen (RETIRED)
2010-04-06 11:25:27 UTC
http://wiki.debian.org/HALRemoval https://wiki.ubuntu.com/Halsectomy http://fedoraproject.org/wiki/Features/HalRemoval Do not remove optional HAL support from packages, thank you. You are removing important features from x86-fbsd and amd64-fbsd. They don't have udev as an option. (In reply to comment #2) > Do not remove optional HAL support from packages, thank you. You are removing > important features from x86-fbsd and amd64-fbsd. They don't have udev as an > option. > Not exactly agreeing on your defininition of important, when X.org and the major desktops have migrated away from HAL, the optional HAL support will be gone also for the low hanging fruits. Maintainers can decide for themselfs what's the best course of action (removal, bump, replacement, ...), the bugs stay open until that has been determined. I believe X.org will be working with HAL as well as an option in 1.8, with udev encouraged instead of HAL where possible. Maintainers can decide for themselves, but they aren't exactly getting all the relevant information about his in all these bugs, in relation to BSD and whatnot. The information given really gives no doubt that it's useless to have in all cases, while that is definitely not true. When the optional HAL support goes away, then the USE flags and optional deps on hal will go away naturally. The goal here should at first be to ensure the possibility to go without HAL while not losing any features, NOT force removing said functionality from systems where the replacement doesn't work. For the record, we (the x11 herd) will provide HAL support probably for the whole duration of 1.8. This is of course subject to change, but that's what we have in mind right now. We have yet to get a lot of testing of the udev autoconf backend, so HAL will still be an option for a while. Cheers Please add bug #292281 to the dependency list, as k3b also depends on hal. Thanks. bug 311093 also depend on this Sorry, that is the opposite, this bug should depend on bug 311093 (In reply to comment #0) > If you can replace hal with udev in your package, good. > If the support is optional, drop it. > Hal is dead. This route isn't perfect as it removes important features from packages. HAL may be dead but is still working fine. Why not masking it in profiles with (g)udev support when there is a udev replacement? that'd please everyone I think. Also, this doesn't seem to be a bsd only issue. >=udev-141 which I believe is the one with gudev support is masked on uclibc profiles: http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/uclibc/package.mask?r1=1.17&r2=1.18 From solar's commit message it seems there are glibc specific features. IMHO killing HAL like that is way too quick. If there is only (g)udev support, then fine, if upstream wishes to support something else than linux/glibc, then there is only a loss of functionality in forcing hal to be disabled. (In reply to comment #9) > Also, this doesn't seem to be a bsd only issue. >=udev-141 which I believe is > the one with gudev support is masked on uclibc profiles: > http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/uclibc/package.mask?r1=1.17&r2=1.18 > From solar's commit message it seems there are glibc specific features. uclibc issue is bug 272199 which will be solved by bug 308477 afaik also sys-power/upower is only waiting for ~x86-fbsd keywording ... [ snip from configure.in ] elif test -e /usr/include/dev/acpica/acpiio.h ; then with_backend=freebsd [ end of snip ] I don't see a dependency on kde-base/powerdevil - it needs hal for power management (battery monitoring, etc). Upstream bug about KDE & hal: https://bugs.kde.org/show_bug.cgi?id=229643 KDE SC will stop require HAL in 4.6, where initial upower and udisks support has been commited. I just noticed, that gnome-extra/gnome-power-manager has the hal USE flag enabled by default on my system. Is there any reason for this ? (In reply to comment #14) > I just noticed, that gnome-extra/gnome-power-manager has the hal USE flag > enabled by default on my system. Is there any reason for this ? Yes, we like users to have important features by default. It provides better brightness handling support and a couple other things. That said, it probably used to be for much more stuff (power handling, etc), so if filed in a separate bug, we could re-consider it there. The flag will definitely stay there for 2.30 - removing it would simply be irresponsible to our users, as it provides things some need. The default is another question. It doesn't look too bad right now, http://tinderbox.dev.gentoo.org/misc/rindex/sys-apps/hal http://tinderbox.dev.gentoo.org/misc/dindex/sys-apps/hal If anyone wants to help, pick a package and start checking for bumps/replacements/etc. File bugs linked to this tracker. Just skip Xfce4 (already fixed in p.masked version), pcmanfm, KDE, ... for now (In reply to comment #15) > (In reply to comment #14) > > I just noticed, that gnome-extra/gnome-power-manager has the hal USE flag > > enabled by default on my system. Is there any reason for this ? > > Yes, we like users to have important features by default. > It provides better brightness handling support and a couple other things. This sounds quite reasonable, nevertheless gnome-power-manager is then a blocking requirement for the removal of hal. > The flag will definitely stay there for 2.30 - removing it would simply be > irresponsible to our users, as it provides things some need. The default is > another question. I was just wondering, whether a better replacement for the hal functionality in gnome-power-manager is available yet. Removing hal without an appropriate replacement is a bad thing to do, IMHO :) The use flag is there for a reason, it means you can choose if you want to depend on it or not. The USE flag will die naturally when upstream of the package comes up with a replacement. Waiting for official documentation ;-)... an useful HOWTO remove Hal (tnx Samuli) http://forums.gentoo.org/viewtopic-t-858965-highlight-.html KDE 4.6 is stable, KDE 4.4 has been removed. sys-apps/hal is no longer in portage all hail udev |
