[RFC] Upgrade path for Precise i386 non-pae generic flavor

[Tim Gardner]

On 05/17/2012 07:40 AM, Leann Ogasawara wrote:
> On 05/17/2012 05:40 AM, Tim Gardner wrote:
>> On 05/16/2012 03:21 PM, Leann Ogasawara wrote:
>>> Hi All,
>>>
>>> I'd like to discuss and get feedback regarding the best solution for
>>> smoothly upgrading PAE capable systems currently running a non-pae
>>> kernel and then collapsing the generic-pae flavor back to a generic
>>> flavor.  I've broken this down into 2 phases, which I'll describe below.
>>>
>>> Phase 1 is smoothly upgrading PAE capable systems running the Precise
>>> i386 non-pae generic kernel to the Quantal i386 generic-pae kernel.
>>> I've attached a patch which I believe will do the job, but would like
>>> some review and feedback.  I would add that I have tested this patch on
>>> an i386 PAE capable system which was running the Precise i386 non-pae
>>> generic kernel.  It properly allowed updating to the Quantal generic-pae
>>> kernel.  I also ran a quick test on an amd64 system to check I hadn't
>>> regressed anything in terms of updating.  The only test I'm missing is
>>> for the scenario of a non-pae system attempting to update.  The
>>> expectation is that the update would abort.  I unfortunately don't have
>>> access to this type of system.  I would like to get confirmation for
>>> this scenario before proceeding.
>>>
>>> Phase 2 is transitioning the current generic-pae flavor in Quantal to
>>> become a generic flavor.   I unfortunately don't believe it's possible
>>> to do both phase 1 and 2 in the same development cycle as we could find
>>> ourselves in a scenario of having recursive install dependencies.  In
>>> order to do both, I believe it will have to span two development
>>> cycles.  I'm happy to be wrong here if someone can point it out to me.
>>>
>>> My current proposal is we do phase 1 in 12.10 (ie Quantal) and phase 2
>>> in 13.04 (ie R).  Comments appreciated.
>>>
>>> Thanks,
>>> Leann
>>>
>>>
>> I don't think it needs to be that complicated. The goal is to transition
>> Precise meta packages to Quantal in one upgrade step. We only need to
>> support that one scenario, e.g., Precise ->  Quantal, because I think its
>> policy that we only support upgrades from LTS to LTS, then LTS to
>> intermediate releases.
>>
>> server [i386 amd64] ->  generic [i386 amd64]
> 
> I think this was already handled when we did away with the server flavor
> in Precise.
> 

Doh! You are correct.

>> virtual [i386 amd64]->  generic [i386 amd64]
> 
> Have we confirmed we are able to collapse the virtual flavor for Quantal?
> 

Yep - Andy should be pushing a patch for that today.

>> generic [i386 amd64] ->  generic [i386 amd64]
>> generic-pae [i386] ->  generic [i386]
> 
> So if I'm thinking out load, the first step for us is to re-instate the
> i386 generic flavor in Quantal which will be identical to the current
> generic-pae flavor in Quantal.  Once that is in place we could then
> re-direct the Quantal generic-pae meta package to the generic meta
> package and at the same time re-instate the i386 generic meta package in
> Quantal.  Then we'll rely on update-manager-core to reap the obsoleted
> packages (ie generic-pae meta packages)
> 

I agree except for 're-direct the Quantal generic-pae'. That package
simply disappears. Quantal developers caught in an intermediate state
will have to perform some manual magic.

>> lowlatency-pae [i386] ->  lowlatency [i386]
>> lowlatency [i386 amd64] ->  lowlatency [i386 amd64]
> 
> This is implying that we're taking back ownership of the lowlatency
> kernel flavor.  Have we committed to doing that?
> 

I committed to the lowlatency flavour _iff_ we could collapse virtual
into generic. I am under the assumption that the lowlatency flavour is
no more then config changes, and one ifdef. If not, then I'll have to
reevaluate my position.

rtg
-- 
Tim Gardner tim.gardner at canonical.com