On Wed, Sep 28, 2005 at 03:33:34PM -0500, Manoj Srivastava wrote: > On Wed, 28 Sep 2005 21:15:59 +0200, Sven Luther <[EMAIL PROTECTED]> said: > > Ah, you are wrong, if the scripts where using debconf, then you > > could preseed it, or use the non-interactive mode or whatever. > > Wrong, eh? Indeed, it is you who have no idea whast is being > talked about here. Even if debconf is used, the kernel image can > choose to abort install unless a human answers the question, and that > is likely to be what shall happen when I code debconf in.
Ok, well, but from my experience with d-i and kernel installation, those questions which usually show up (at least on a powerpc install), where hardly of the kind that could no be worked around, especially since the installer knew better than the user about those. > > The current questions are mostly worthless (at least on powerpc) > > anyway, and are just an annoyance that should go away. > > Opinions with no rationale are unlikely to sway me on this. The powerpc scripts are outdated and have no relationship to reallity since a couple of years. I end up being asked about quik and such on my pegasos machine, which is pretty annoying. I know this is partly my fault, since i didn't take time to fix this correctly, but i guess now is the time to solve this, possibly in conjunction with said bootloaders and the kernel team. The same seems to happen about the link in boot and other such options, which with the new kernels may or not be still uptodate default choices, at least i heard some comments about this earlier. > > I believe that the kernel package should work out of the box and not > > need manual intervention to set the initrd thingy, since the kernel > > image knows perfectly that it needs an initrd or not, so why have it > > have the logic to know about it and tell the user instead of just > > doing the right thing ? > > Again, you seem to be missing the point. Some boot loaders > require intervention before they can handle initrd images (indeed, > booth grub and lilo do, as far as I can tell). Unfortunately, it is No, i know this perfectly. What i am saying is that in most cases, the bootloader maintainer and the kernel-package/kernel-team maintainers know more about this kind of thing than the end user, and are able to make the right choice. This is something which i have been thinking about for a while, and it is my profund conviction that the solution is one where the bootloaderis, the kernel packages and kernel-package need to be working together better, since between themselves those have the knowledge you point out above, and if there is user intervention needed, the choices can be added to the debconf database once and for all, with varrying degree of questions and default depending on the priority. Each bootloader would provide a debconf hook to be chosed as default bootloader, and it will know what to do to make the kernel and initrd installable, and provide the adequate kernel post-inst hooks for it to work. The user, if he installed more than one bootloader, will be able to chose in debconf the bootloader which is going to be active, and this one will do the right thing. It needs some maturation, experimenting, and implementation, but i have the strong believe this is the right solution, and would solve all those issues. > not feasible to know what boot loader is being used (I have both grub > and lilo on my machines), nor is it feasible to tell whether the boot In today's setup, you are right :), but i believe we should be able to come up with somewhat better for etch if we start soon enough. > loader can handle initrd's -- and no way am I goona add bunches of > code to parse every tom dick and harry bootloader config script. Indeed, but if the bootloaders provided those ? > As I have said elsewhere in this report, working correctly, > and not rendering the system unbootable, trumps non-interactive > installs. Indeed, but let's try to do the right thing and allow both for etch, i believe it is possible, altough there may be issues you have more experience with and which i may have missed which may make the above plan not work, but i believe it is the right way to solve those issues. > > I think now is the moment to think about the futur of > > kernel-package, and what will happen to it for etch. Could you tell > > us a bit more about what your plans are for that ? > > My plans are not to remove functionality that makes it easy > for novices to use packaged kernel images. :) The alternative being the official kernels doing their own stuff, which i believe is not the aim here. > So, debconf or no debconf, there is no surety that kernel > images shall install when debconf frontend is set to non > interactive -- unless there is some way to dete t that proceed shal > not hose the end user system. Indeed, but debconf and a proper large-scale plan should be able to solve this where kernel-package alone could not. This is also the logical continuation of the work done by the kernel team, and i hope you can add your experience and knowledge to help us evolute this in the best possible solution for etch. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
