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

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

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]
virtual [i386 amd64]-> generic [i386 amd64]
generic [i386 amd64] -> generic [i386 amd64]
generic-pae [i386] -> generic [i386]
lowlatency-pae [i386] -> lowlatency [i386]
lowlatency [i386 amd64] -> lowlatency [i386 amd64]

The recommended upgrade method is to use update-manager-core, e.g.,
'sudo do-release-upgrade'. That is a programmatic way of inserting new
packages that have no prior relationship, or removing packages that have
been obsoleted.

We don't really have to worry about the meta package mess we have in
Quantal right now. Lets just code for what we've speced for Quantal and
the reaper will eventually cleanup all of the obsoleted meta packages
(as well as kernel packages when virtual and generic-pae disappear).

rtg

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.

> virtual [i386 amd64]->  generic [i386 amd64]

Have we confirmed we are able to collapse the virtual flavor for Quantal?

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

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

Thanks,
Leann

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