[Bootmenu-devel] Bootmenu in extras(-devel)?

[Carsten V. Munk]

Frantisek Dufka wrote:
> Great. I had a quick look, it seems to work. Any reason why 
> debian/compat and debian/control uses debhelper 5? I guess it is just 
> the way it was generated. Gregale sdk uses version 4 so I tried to 
> change it to 4 and it seems to work too. Maybe it can be downgraded? I 
> only see
> dh_gencontrol
> dpkg-gencontrol: warning: unknown substitution variable ${misc:Depends}
> dh_md5sums
> when building in Gregale but I see it in Diablo SDK (version 5) too.
>
Yeah, - it was made by dh_make and it probably defaults to 5, if it
works with 4 then sure
>
> OK, no problem. I'd prefer to beat it into shape a bit before doing it 
> (maybe version 1.4?) but I don't care too much if you insist :-)
>
I knew there was things that probably needed to be beat into shape so
that was the whole point of this mail :)
> Things I'd like to solve before doing that
> - install_bootmenu vs refresh_bootmenu.d - they are modified copies of 
> original initfs_flash, shared code should be moved somewhere else
We can probably . in some shared methods
> - agree on somewhat final syntax of *.item files, or is it already too 
> late? ITEM_ prefix is somewhat redundant, this is related to the way 
> it is handled in for loop which should be fixed to handle any random 
> WHATEVER => MENU_X_WHATEVER option.
I kinda like the ITEM_ notation because it establishes a namespace and
no matter what we do of changes in bootmenu / include variables, we
won't accidentially overwrite anything, but it's not too late to change
as it's only deblet installer using the notation for now as far as i know
> - decide how to structure optional/extra features (dropbear, ...) so 
> they can be included/omitted in the build (similar to 770 vs N8x0 
> issue below)
>
Well I guess the challenge is - is the bootmenu package an automatic
initfs flasher or a bootmenu installer (where you click an icon to
install, and then select your options)?

> Would be nice to have build process that includes only things that 
> makes sense (like no 770 specific files in diablo version).
> I tried to fix curent bloated size because of no symlinks in your 
version. Looks like it works and svn can hadle symlinks fine (did only
utelnetd now, will do the rest). But even with symlinks size can grow so
it is preferred to omit 770 vs N8x0 versions.
>
> Is there a way to test current sdk version when building package?
>
I'm not sure about this one, I'll look into it
>>
>> * One step for updating boot menu, - upload source package to extras 
>> builder
>>
>> Possible issues:
>>
>> * When to promote bootmenu from extras-devel to extras
>
> extras is defined as "it will not brick your device", tricky target 
> for bootmenu :-)
Mm, yeah - but if people start supporting bootmenu items and community
edition too .. i haven't heard about direct corruption from bootmenu?
Except for the dreaded WSOD?, and if the bootmenu doesn't fit the initfs.
>
>>
>> * debian/copyright & README's should probably be edited
>>
>> * Choice of maintainer (bootmenu-devel at garage.maemo.org maybe and a 
>> shared pgp
>> key?)
>
> maybe, not sure how this is done in other projects, or it can be you 
> or me directly
>
Yeah, we'll see when it's more beaten into shape :)

/Stskeeps