On Thu, 2013-03-21 at 12:52 +0900, Nobuhiro Iwamatsu wrote: > Hi, > > On Wed, Mar 20, 2013 at 12:17 AM, Paul Wise <p...@debian.org> wrote: > > On Tue, 2013-03-19 at 15:05 +0000, Ian Campbell wrote: > > > >> I think the question here is what the `uname -r` bit should be. > >> Specifically the $FLAVOUR in 3.x.y-z-$FLAVOUR. > > > > Woops, I missed that uname -r includes the flavour bit. > > > >> I think there is an argument for making the multiplatform case be the > >> default "no-flavour flavour" i.e. $FLAVOUR is armhf/arm64 etc. Or > >> maybe that's what you are suggesting having not realised that `uname > >> -r` currently includes the -$FLAVOUR suffix. Hrm, I think we may > >> actually be talking about the same thing ;-) > > > > Right, my suggestion is just to use the architecture for the flavour, as > > is done on the other architectures. > > > > Thank you for your comment. > > In ARM ((but may be used on other architectures as well) ) all architectures, > flavor with the name of the CPU do is that it is multiplatform? > For example, armv7 flavor is multiplatform support in armhf.
A single multiplatform kernel can support both armv6 and armv7 (or armv4 + armv5). I don't know if Debian plans to have separate versions for each architecture version - there may be performance benefits to this - in which case using armv6 -v7 etc sounds like a good idea. Also, a multiplatform kernel can't support armv5 and armv6, so there may need to be more than one 'mp' version anyway. -- Tixy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
