https://bugzilla.novell.com/show_bug.cgi?id=449853
User tvrtko@ursulin.net added comment
https://bugzilla.novell.com/show_bug.cgi?id=449853#c15
--- Comment #15 from Tvrtko Ursulin
(In reply to comment #13 from Tvrtko Ursulin)
"Online update only" means post release? It is not clear to me (from above discussion) whether until then we get full USB 2.0 speed or not? If not then rather than shipping with a serious performance issue (just to release an update effectively immediately?) I would rather delay the product and have it shipped in a better shape.
And in the end we will never ship. Because there will be always a bug that causes the delay. But I can only give recommendations. The decision will be made by the project manager (Stephan Kulow).
This is still under the assumption that with this setup we don't get USB 2.0 full speed? I wanted to check that myself but found out my external HDD does not work any more (raised another bug about that) so I don't know. But I would be surprised because that would mean no one tested the betas with USB 2.0. I hoped there are more early adopters than that... But my point is that I don't think it is that much less risky to push an update after the release if it is so quickly after that it still won't get wide testing coverage. If it's broken you still break a lot of systems (except those who don't update) and the only way you can get wider testing is to push it in the wild (slight assumption here again). Think of the bad press - openSUSE 11.1 is out but USB 2.0 does not work? So what's another RC.. make it done when it's ready.
Also, from what is is worth, I don't really think dependency data in comments is a good and robust solution. Why the whole problem with initrd and modprobe.conf if I may ask? It would make most sense if initrd would use modprobe.conf in the same way "full system" does. Single point of configuration, single rules, single behaviour.
We use the same configuration. But we need to decide which programs and modules we include in initrd (or do you think we should include the hole hard disk in initrd). There are four options
1) Hard-code such things in initrd. 2) Use the comments I implemented. 3) Express dependencies not in install lines but with an additional mechanism (which may be done for 11.2). 4) Try to parse the install lines. That is error-prone. I don't want that.
I used (2). Point.
I don't think we should put everything into initrd, just that there must be a better way than the one chosen, because it is redundant, and that is usually a bad sign. I was thinking about teaching modprobe to dump desired information and now I see what you mean with not wanting to parse install lines, they seem to be shell code snipets. Maybe extending modprobe to support more verbose operation so it prints out what modules would it load so you can do something like: # modprobe -v -n --show-insmod ohci_hcd WOULD-INSMOD: usbcore.ko install ohci_hcd /sbin/modprobe ehci_hcd WOULD-INSMOD: ehci_hcd.ko WOULD-INSMOD: ohci_hcd.ko Or some other special output formatting.. I see that this could work, no? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.