On Mar 05, Sven Luther <sven.luther@wanadoo.fr> wrote: > Well, i remember some issues with the firewire module in the sarge timeframe, > and how you actively discouraged a workaround for this. It's hard to be specific since I do not remember the details either, but IIRC I suggested a solution to be implemented in the libraw1394 package. The reason was that the kernel firewire code is close to be unmaintained and there was no plan to add whatever was needed. I do not know if it has been fixed since then, but at least it still does not provide a way to support events synthesis for devices plugged at boot time. > > I have no such plan. Just do not expect to implement hacks in my own > > packages unless there is a timeline for their replacement with proper > > fixes. > So, on one hand you say you have no plan to oppose workarounds, but on the > other hand you clearly oppose such workarounds ? No, I oppose attempts to require me to maintain them indefinitely in my own packages. It is still possible to add to other packages the rules and scripts needed. > I propose you give some clear guidelines of what will be acceptable and not, I am happy to implement compatibily hacks as long as there is a clear plan to remove the need for them in future kernel versions, like a patch which will soon be submitted to the maintainer of the relevant subsystem, and there is no better package to contain them. Or if they are like /lib/udev/modalias_ieee1394, which is unobtrusive enough that I do not mind maintaining it in udev (it is trivial and it will just be ignored when the firewire stack will support $MODALIAS). > Also, i would be interested in how your vio and ide hacks described above fit > in these guidelines. Respectively 2.6.15 and 2.6.16 implement $MODALIAS, so the rules file will stop calling them. -- ciao, Marco
Attachment:
signature.asc
Description: Digital signature