Re: Areas of Emdebian to integrate into Debian

> On Sun, 3 Apr 2011 17:15:52 +0100
> Hector Oron<[email protected]>  wrote:
>
>> 2011/4/3 Neil Williams<[email protected]>:
>>
>>>>   * 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?
>
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.

>>> 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/492
>>
>> Nothing 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.
>>
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.

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