Thread: [Debian] Alpha(?) testing of new Deblet installer and Bootmenu installer.
View Single Post
Stskeeps's Avatar
Stskeeps is offline Stskeeps
2008-08-21 , 09:09
Posts: 1,671 | Thanked: 11,478 times | Joined on Jun 2008 @ Warsaw, Poland
#7
Originally Posted by fanoush View Post
- with deb package one doesn't need sudo gainroot, you can modify sudoers and get rid of the hack
Ah - I think you're thinking that my deb package installs right away -it doesn't, it has a icon that runs it using osso-xterm -e /usr/sbin/install_bootmenu - which isn't run as root. I agree modifying sudoers could work too, but you also have the sudo gainroot hack in initfs_flash which is why I decided on this solution

- it may be good to have basic bootmenu flasher deb with no dependencies on gui stuff and python (actually with no dependency at all if possible), the gui can be separate deb for those who really need it
The bootmenu.deb has no dependancies - it even uses osso-xterm -e, it's just the deblet installer that has them.

- current code with merging ITEM_WHATEVER is hardcoded in the script, this can be made generic by not including it directly via '.' but parsing/evaluating it to rewrite any 'WHATEVER=xxx' line automatically into MENU_X_WHATEVER=xxx line
Yeah, that's also a possibility - I took the current solution due to the simplicity and that it's easy to understand what goes on. It's all a matter of how to implement it

- would be nice to modularize both support for different versions of initfs (devices, firmwares) and also optional features (dropbear, telnet, framebuffer console, in future also some advance recovery tools in initfs) current way of including everything inside is not ideal. Also patching Nokia linuxrc should be done differently, currently full modified linuxrc is stored for each different firmware. This could allow autopatching unknown new firmware.
Indeed - One possibility that the _linuxrc setting has is that since it avoids using Maemo boot, .. think ext2.img file systems on fat fs MMC including optional features. Think LINUXRC="/dropbear/dropbear.linuxrc" that starts it up by mounting /dropbear/dropbear.img on the fat system and starting the dropbear file inside it..


- merging final bootmenu.conf can be done already in flasher, not at boot time (for speed and smaller initfs runtime code with less bugs, bugs at boot time are nasty), those parts can be still kept separate (in initfs) for future merging. Still some on the fly modification when already booted into menu would be nice too, so maybe the merging could stay in initfs too but not in normal execution path.
I have no direct preference on how to do it - i'm happy as long as there's a /etc/bootmenu.d/*.item thing that refresh_bootmenu.d refreshes initfs boot menu using.

- I'd like to keep simple .tar.gz format too, some people prefer it, sometimes you don't have system with full debian installed or you don't want to mess with repositories so the code should be written to be both buildable into deb with /var /lib /bin /etc paths and one directory
Yeah, there's nothing to stop you really from doing tar.gz's as such - I just did this modification to make things easier and more "deb" like - should obviously have both possibilities and share same code base


So these are things I have planned. I certainly cannot tell people what they should do but if you want to help instead of doing yet another quick bootmenu flasher hack, it would be nice ;-)
My intent has been all along as it to be patches for your bootmenu - I have no interest in maintaining bootmenu software - so I'm all ears on how to change things to improve upon your bootmenu and maybe include in the more "official" distribution - I've used your bootmenu for a long time myself and find it immensely useful.
__________________
As you go on to other communities, remember to build them around politeness, respect, trust and humility. Be wary of poisonous people and deal with them before they end up killing your community.. Seen it happen to too many IRC channels, forums, open source projects.