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? > > 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. > > Is not that a way around device trees? 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. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpTgCrngfZsp.pgp
Description: PGP signature