From Fedora Project Wiki
(Comment about packages using HAL through D-Bus.) |
No edit summary |
||
| Line 1: | Line 1: | ||
= Questions = | = Questions = | ||
Will anything using hal now need to be ported by F10, or will that keep working? | # 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 | ||
In particular I am wondering about thunar-volman (the Xfce Thunar plugin that handles removable devices). | #*"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 | ||
Is the any docs or API info that I could point upstream thunar-volman at? | # Would we really roll back this feature if the KDE side of things isn't done in time? - JesseKeating | ||
- kevin | #*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? | |||
"anything using hal" - no. See scope: things using hal for disk information will | #*anaconda integration will happen when the anaconda team decides that it is the right thing to do. - Matthias | ||
have to be ported, such as gvfs, Solid and thunar-volman. I've added a link to the api docs. - 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. --[[User:Kkofler|Kkofler]] 21:25, 11 July 2008 (UTC) | |||
Would we really roll back this feature if the KDE side of things isn't done in time? - JesseKeating | # 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 | |||
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 | #How about a hal compatibility layer? | ||
David to say in detail. - Matthias | #*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 | ||
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 | |||
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 = | = FESCo 2008-07-10 = | ||
* This feature is not ready for acceptance the questions from FESCo are above | * 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. | * Please move feature page to Category:ProposedFedora10 when your page is ready for re-review. | ||
Revision as of 13:50, 22 July 2008
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.