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

[Frantisek Dufka]

cvm at daimi.au.dk wrote:
> I've just committed a proper debian package skeleton instead of the hacky
> build-deb, so we can both distribute a dpkg-buildpackage'd deb and a tar.gz
> which would be source package for both.

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.

> 
> So, since it's dpkg-buildpackage'able now, there has been some interest from for
> instance the community edition (and the people wanting to reduce repositories
> and have central extras, so Deblet installer repo should be at a minimum), to
> have bootmenu in extras(-devel), and I'm wondering what your opinion(s) are
> regarding putting bootmenu into extras-devel initially?

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 :-)

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
- 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.
- decide how to structure optional/extra features (dropbear, ...) so 
they can be included/omitted in the build (similar to 770 vs N8x0 issue 
below)

> * Easier way to push updates when new initfs comes out - just push a new source
> package to extras builder (and when community edition gets in gear, there might
> not even be problems for clone-to-SD and stuff when initfs gets flashed by the
> updater)

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?

> 
> * 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 :-)

> 
> * 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

Frantisek