No edit summary |
(/me fails to understand how wiki-based discussion works) |
||
| Line 3: | Line 3: | ||
Is the any docs or API info that I could point upstream thunar-volman at? | Is the any docs or API info that I could point upstream thunar-volman at? | ||
- kevin | - kevin | ||
"anything using hal" - no. See scope: things using hal for disk information will | |||
have to be ported, such as gvfs, Solit 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 | 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 thats for | |||
David to say in detail. - Matthias | |||
What about anaconda integration? | 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? | 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. | 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? | 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 | |||
Revision as of 18:07, 10 July 2008
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, Solit 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 thats 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
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