Am 01.07.2010 15:13, schrieb Daniel Baumann:
as said in 573042, patches or concrete specifications how things should
be handled and just need to be implemented, are welcome.
At the moment it's more like an idea, roughly based on GRUB2's
/etc/grub.d mechanism:
The extlinux-update script should be split into several parts that
reside in /etc/extlinux.d. That is, extlinux-update will have to get
modified to merely call the scripts in /etc/extlinux.d in lexical
order. Something like
for i in $(ls -1 /etc/extlinux.d | sort -u) ; do
if [ -x $i] ; then sh $i ; fi
done
The first ~116 lines of extlinux-update, that handle the regeneration
of /etc/default/extlinux, could go into e.g.
/etc/extlinux.d/05_default. The next lines up to ~213, which handle
the creation of /boot/extlinux/linux.cfg, could go into e.g.
/etc/extlinux.d/10_linux. Etc.
Other kernel images could then drop a script e.g.
/etc/extlinux.d/20_memtest86+ (which could also be provided by
extlinux itself for the time being), which checks for the existance of
the corresponding image (e.g. /boot/memtest86+.bin) and creates a file
like /boot/extlinux/memtest86+.cfg pointing to the appropriate image
file location and finally leaves a line in
/boot/extlinux/extlinux.conf to include /boot/extlinux/memtest86+.cfg.
Themes would be no different, as they could also drop a script e.g.
/etc/extlinux.d/06_theme-debian-squeeze which sets background image
and colours and then take care they get included from
/boot/extlinux/extlinux.conf.
How do you like this idea, did I miss something?
- Fabian
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
