Hi, Ian Campbell <ian.campbell@citrix.com> (2014-04-19): > Now that armhf only has a single kernel flavour I think we can simplify > the installer setup a bit. > > Firstly by moving the armmp subarch to the top level and secondly by > dropping the version from the kernel filename. Leading to > installer-armhf/201403XX/images/netboot/initrd.gz > installer-armhf/201403XX/images/netboot/vmlinuz > rather than > installer-armhf/current/images/armmp/netboot/initrd.gz > installer-armhf/current/images/armmp/netboot/vmlinuz-3.13-1-armmp > (similar for netboot-gtk and network-console). I see no objections in doing so. Worst case, if the need for a new subarch arises, we can reintroduce subdirectories… I'm not exactly sure how many consumers of these images there are. But I guess anybody unhappy about the change can yell at us, so that we know. :) > Since dropping the version suffix requires a kernel udeb change as > well I think the best time to make the change would be as kernel 3.14 > goes into unstable. So I plan to make the kernel change in svn soon > unless someone objects and defer the d-i bit until it is uploaded. Sounds very sensible to me (with s/svn/git/). > I also think it would be useful to include the DTBs in the installer > output, since they are needed almost everywhere these days and are > sometimes not all that easy to get hold of (I had an idea there was a > related bug report, but I can't find it). I've got a patch which copies > all the packaged DTBs into the installer: > moves all > installer-armhf/201403XX/images/device-tree/sun6i-a31-colombus.dtb > installer-armhf/201403XX/images/device-tree/omap3-igep0030.dtb > installer-armhf/201403XX/images/device-tree/imx27-apf27dev.dtb > [... many more...] > This also applies to the armel/kirkwood subarch > installer-armel/201403XX/images/kirkwood/device-tree/kirkwood-mplcec4.dtb > installer-armel/201403XX/images/kirkwood/device-tree/kirkwood-lschlv2.dtb > installer-armel/201403XX/images/kirkwood/device-tree/kirkwood-ns2max.dtb > [...] > > I'm a bit worried that this might imply a greater level of support for > any board with a DTB than we actually offer. Not really sure how to deal > with that, probably more of a docs issue than anything. I'm going to trust arm* people's judgement on this topic. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature