On Sat, May 25, 2013 at 3:08 AM, Turbo Fredriksson <tu...@bayour.com> wrote: > On May 24, 2013, at 8:54 PM, Aron Xu wrote: > >>>> 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... >> >> It could be possible, but I don't think building it is acceptable, >> because it means you must pull in everything of build-essential to the >> d-i image, which is useless for most other people when they run d-i. > > Ah, ok then I think I know what you mean. I thought you meant when the > d-i image is built... > > But how does this help keeping 'the current kernel' and the OOT's up-to-date? > > From what I think I understand of you proposal, the user. Which means we > can't offer 'whatever-support-the-OOT-provides' globally in our install > images. It would be up to the user to make sure that this is available. > > > I was kind'a hoping we could do this as an organization and provide this > for our users, instead of putting it to them to make it available for > themselves.
Now I understand what you mean, just use DKMS to build OOT modules at image generation time? Seems to be a good idea. -- Regards, Aron Xu -- 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/CAMr=8w6v=4b1+azgn2a4zub9znfsxmg30ntxdrlbaceucou...@mail.gmail.com
