[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dropping 686 non-pae kernel



On Sun, 2011-03-13 at 17:13 +0000, Ben Hutchings wrote:
> On Sun, 2011-03-13 at 09:18 +0100, Bastian Blank wrote:
> > On Sun, Mar 13, 2011 at 03:57:56AM +0000, Ben Hutchings wrote:
> > > On Mon, 2011-02-14 at 11:34 +0000, Ben Hutchings wrote:
> > > > On Mon, 2011-02-14 at 11:23 +0100, Bastian Blank wrote:
> > > [...]
> > > > > There are several possibilities to do this:
> > > > > * Change name of meta-package:
> > > > >   - Breaks nothing
> > > > >   - Needs manual intervention by anyone using it
> > > > > * Don't change the name:
> > > > >   - Breaks some systems
> > > > >   - No manual intervention by the rest
> > 
> > > I'm wavering on this.  I don't like the idea of simply renaming
> > > '686-bigmem' to '686', given there are a fair number of 686-class
> > > systems without PAE, and I don't think users with a Pentium M are going
> > > to expect that '486' is the right choice.
> > 
> > Please read again what I wrote.
> 
> The fact that changing the metapackage name is disruptive?  Ever heard
> of transitional packages?
> 
> > > The distinctions between these two flavours will be:
> > > 1. One processor (min 486) with 386 page tables (currently '486')
> > > 2. One or more processors with PAE page tables (currently '686-bigmem')
> > 
> > Will not hold forever and you need to integrate the other architectures
> > into it.
> [...]
> 
> I would expect the minimum processor for (1) to increase over time
> (hence my suggested name change), but other than that, what would need
> to change?  Major new x86 features seem to be restricted to Long Mode
> only now.

Alternately we could go for the less disruptive renaming of '686-bigmem'
to '686-pae', and defer renaming of '486' until we actually bump the
processor requirement.  This would also give us flavour names that
closely mirror those found in other distributions.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: