But is it reasonable for a cross build mirror repository to be created so that they can be diffd thus developing a huge database of cross built vs natively built packages to validate the crioss building process it self. If, after a year, that packages are identical it would be good evidence to support cross built repositories. Conversely, if the packages differ, we really might like to know that and may provoke investigation as to why.On Sun, 3 Apr 2011 17:15:52 +0100 Hector Oron<hector.oron@gmail.com> wrote:2011/4/3 Neil Williams<codehelp@debian.org>:* Add a field which allows a package to be cross buildable (that might be delayed until we gain support for all that in Debian)I'm not sure about this one. I think every package should be assumed to be cross-buildable until proven otherwise.Sorry, my use case is setting a flag which allows Debian autobuilders to cross build a package, instead of natively build. Why do we want that? ARM autobuilders take about 24hrs to complete current official supported kernel builds, that is a big blocker to add more platforms and think as well when there is a security flaw which needs to get fixed, Debian kernels have to delay the fix until all architectures are built. This is one situation where cross building could improve status quo.Personally, I doubt that ftpmaster will accept cross-built packages into any "official" Debian repository for quite some time, if ever. Cross-building support tools is one thing. Cross-built packages are quite another. Have you had ANY indication that ftpmaster is even slightly keen on such a division?
This is sort of true. It does require that the bootloader can be customised to add that command line option. Its a source code hack in bootldr for example. Kernel command line setting is only one way of runtime configuration. If the platform variant can be detected early in the boot process then a similar effect can be acheived.There's a completely different argument here about why we *have* so many variant boards which need varying kernel support. Kernel people aren't happy with the constant variability of board-specific support systems. Personally, I question whether each individual board needs to have a bespoke config supported by bespoke patches which conflict with other bespoke patches for other similar boards, so I'm with Linus on this one. https://lkml.org/lkml/2011/3/17/492Nothing we can do to solve current situation.Wrong. We can at least push people to collaborate, provide the tools where we can and act appropriately when doing our own kernel stuff (like in balloon).Recently, balloon added support for having a single kernel for multiple board configurations and handling the results via the vmlinuz.cmdline support. That would seem to be the way forward to me because then we could have a single set of patches which enable everything (even if not present on a particular board) and then rely on the specific commandline for that specific board to sort things out at boot. This also lends itself to runtime kernel package upgrades and easier porting of the patch set to newer kernels because more people are working on the same patches, not their own.
Note also that Debian boots via an initramfs/initrd with all(?) modules installed which it then replaces with the rootfs. This makes the image rather large and possibly not ideal for embedded - do we need all the LVM/RAID/SCSI module bloat just to boot our embedded device? Balloon solves this by booting a uclibc kernel/initramfs with a reduced module set off which it kexecs the main rootfs.
Is not that a way around device trees?
Which needs bootloader support too.
Possibly - the point though is that the patches get collated and worked on together.Should we provide security fixes on those out of mainline tree kernels? Or should we just build kernel versions which are marked as long term support (2..6.32,2.6.37) and/or long term support for embedded (2.6.35)?We don't have limitless resources.Sure, that is why, we could concentrate in one version, the one tagged by embedded community (which hopefully will be the same that kernel guys tag as long term support, in the future). It would not be such a pain to get this one kernel version right for next release (and probably it might be linux kernel that Debian and other distros release).... and encourage everyone talking about kernels or wanting kernels from Emdebian to work as part of a larger community and collate patches. We don't have to do the work. We can encourage those who do the work to try and make things go more smoothly.