On May 24, 2013, at 7:04 PM, Aron Xu wrote: > and help d-i people to handle the brokenness > if a change in kernel makes the OOT module does not build
This should only happen when a new major version of the kernel comes out, which means it should only happen in unstable.. And we could make it so that it is possible to make that particular OOT skipped (manually or automatically after a specified time), and hence won't be available for that run of d-i. But within a oldstable or stable kernel, only the Debian version changes, right, so... But if a kernel changes a lot and often in unstable, support for that specific OOT will be intermittent. Might not be a huge problem in unstable. Unwanted, but not a huge deal... > What I can think of is to do the trick in d-i, since it already has > the ability to retrieve and load udeb on the fly, and even prompt > users for missing firmware. Maybe even build them using dkms? I saw that you can make d-i build all packages... So adding a extra hook or something that sees that this is a OOT module, then get it's dkms package, build (to a .deb/.udeb which I have patches sent upstream for) it and use that... But either way would mean that the d-i builder have to do the fixing, instead of a group of people (should be the responsibility of the OOT module maintainer(s)). > Such functionality may be reused so that > related udebs can be fetched and loaded when selected, and if all > effort failed just generate an error message. What if an OOT is a network module? Might be needed before the network is up to fetch it... And if it's included in the monolithic image, then it will be up to the d-i builder/uploader to make sure that the module is available, not a group of people... -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e46ce809-7a99-4572-9af2-64ee1f645...@bayour.com
