Questions
- Will anything using hal now need to be ported by F10, or will that keep working? In particular I am wondering about thunar-volman (the Xfce Thunar plugin that handles removable devices). Is the any docs or API info that I could point upstream thunar-volman at? - kevin
- "anything using hal" - no. See scope: things using hal for disk information will have to be ported, such as gvfs, Solid and thunar-volman. I've added a link to the api docs. - Matthias
- Would we really roll back this feature if the KDE side of things isn't done in time? - JesseKeating
- I don't think so. We'd probably look for a way to keep the hal disks part running next to DK-disks without stepping on each others toes, but that's for David to say in detail. - Matthias
- What about anaconda integration?
- anaconda integration will happen when the anaconda team decides that it is the right thing to do. - Matthias
- What Fedora packages would be affected by this change?
- See scope. We might need to do a more detailed analysis of the inverse hal dependencies. - Matthias
- Careful, not all the packages using HAL are linked to one of its libraries, for example Solid uses it through Qt 4's D-Bus binding only, so the list may be incomplete. --Kkofler 21:25, 11 July 2008 (UTC)
- A porting guide for Fedora packagers would be extremely helpful.
- I agree that a porting document would be useful in general, not just for Fedora packagers. - Matthias
- How about a hal compatibility layer?
- Compatibility layers are generally a bad idea when we can avoid them. From my understanding, the DK-disks api is very similar to the hal disk api, so porting should not be hard. We have the source. - Matthias
FESCo 2008-07-10
- This feature is not ready for acceptance the questions from FESCo are above
- Please move feature page to Category:ProposedFedora10 when your page is ready for re-review.
QA comments about Scope
The scope section has a (partial) list of changes that are expected in F11, but most of those items are either incomplete or not testable:
- Bug fixes in "a number of components, such as kernel, udev, mdadm, lvm."
- Is this a complete list? Could you complete it, perhaps a with tracker bug so we can follow progress?
- "At a very minimum hal needs to talk to DeviceKit-disks about locking and mounting/unmounting."
- Is there a bug id for this, or can you write a small script so we can check to see if HAL is doing this?
- "Core components that we want to have ported for F11 include gvfs, gnome-mount, nautilus and gnome-power-manager."
- Is this the complete list?
- Which ones have been ported and which haven't? I see that gnome-power-manager is using DeviceKit but I'm unsure of the status of the rest.
- How can a normal user check to see if these components are using HAL or DeviceKit?
- "we don't expect to port most of these for F11."
- Are there any you *do* plan to port? If so, can you list them? If not, can you replace "most" with "any"?
Feel free to contact the QA team if you want help or further clarification.
--WillWoods 22:53, 22 January 2009 (UTC)
Will, I don't think there is quite as much unclarity in that section. There is a short list of components that need to be ported to make DeviceKit compelling. That is the first list. And there is a long list of _all_ components depending on hal (that is the second list). As you will notice, there is overlap. Which sort of answers your last question. We plan to port the modules on the first list, which is a small subset of the second list. Some other components may move to depend on DeviceKit/udev on their own, e.g. NetworkManager. For information on what has and hasn't ported, look up to the status section.
-- Mclasen 20:05, 22 January 2009 (UTC)
Okay, I guess I was just confused about whether those lists were complete, because the language implies that some stuff might be missing. I'm going to modify the language in the Scope section to be less ambiguous - e.g. "the core components we plan to port for F11 are X, Y, and Z..." Please correct it if I get anything wrong. Thanks.
--WillWoods 22:53, 22 January 2009 (UTC)