Upgrading to new Ubuntu releases (Re: Announcing Beta release of Ubuntu 6.06 LTS)

[Antony Gelberg]

Matt Zimmerman wrote:
> On Fri, Apr 21, 2006 at 05:34:45PM +0100, Antony Gelberg wrote:
> 
>>Matt Zimmerman wrote:
>>
>>>Sure, more information can be found here:
>>>https://launchpad.net/distros/ubuntu/+spec/release-upgrades
>>
>>Thanks.
>>
>>
>>>"apt-get dist-upgrade" has never truly been sufficient, and this tool is a
>>>solution to that problem, not its source.  Upgrading to a new Ubuntu 
>>>release
>>>is a complex high-level operation which is not easily addressed with the
>>>kinds of heuristics used to support incremental upgrades.
>>
>>Any comment on the suitability of aptitude versus apt-get for the purpose?
> 
> 
> aptitude has a somewhat different implementation, but faces the same basic
> difficulty in that it only has a sea of dependency relationships to work
> with, and no high-level guidance about the goal it is trying to achieve.
> To apt and aptitude, all packages look alike, and it tries to decide
> heuristically which packages are important, and make upgrade decisions
> based on those guesses.
> 
> Have you ever seen apt-get dist-upgrade remove the ubuntu-desktop package
> unexpectedly?  That's an example of a scenario where this approach results
> in a poor upgrade solution.

No.  Why should that happen?

>>>The availability of a GUI tool should not have any impact on users who
>>>choose not to use it.  You may still perform upgrades using the
>>>command-line tools, and resolve any difficulties manually, just as you
>>>always have.
>>>
>>>But for those who want it to "just work", there is now a more suitable
>>>option.  It is a complementary use case.
>>
>>Understood, I think.  I just hope that difficulties won't arise from
>>developers not correcting known problems that would arise with aptitude
>>but not with the new tool.  I think you are saying that both methods are
>>supported, just that one method is less interactive, in which case all is
>>well.
> 
> 
> That's mostly accurate, though the new method is more functional and
> complete.  So while both methods are supported, there are upgrade problems
> which are fundamentally difficult to solve with the traditional approach.
> 
> For example, users upgrading from Hoary to Breezy would typically end up
> with both OpenOffice.org version 1 and version 2 installed, which is almost
> never what the user wanted or expected.  The new upgrade tool understands
> this type of situation, and would know that when upgrading to the new
> release, openoffice.org2 was meant to supersede openoffice.org, and provide
> corresponding hints to apt so that it does the right thing.
> 
> Make sense?

I take your word for it, but why can't Provides: or Replaces: be used 
for the above situation?