dapper -> edgy dist-upgrade holds back essential packages

The held back due to upstart problem is known, just run dist-upgrade a second time.

We figured most people who use APT are used to running it multiple times until it sticks

This is why we have the upgrader. Michael, can you confirm that the upgrader does the right thing? If so, this bug isn't a problem for the final release. Desktop upgrades should use the tool unless the user is comfortable working through situations like this with the command line.

This is going to break server upgrades since we have no such upgrader on them. I don't think targeting it for edgy-upgrades is the right thing to do and we did never had the need to run it twice before. IMHO this isn't nice.

Fabio

Yes, the upgrades deal with both the python upgrades and the upstart upgrade.

The problem with the essential package is that apt assign this property to the installed package, not the candidateVersion. This means that the resolver will not touch it unless a non-essential version is installed.

The problem with the python packages is that python-foo depends on python2.4-foo in dapper, but the upgrade removes the dependency. So the resolver thinks that upgrading means removing a package for no good reason (because python-foo has no rdepends that would enforce a upgrade).

The upgrade enforce the upgrade with a special case for installed python-foo packages.

I have a text-frontend for the upgrader that could be used by server people. We just would need something like the update-manager for the server to actually fetches/executes the upgrader. A simple shell script will be enough (wget/tar is all needed). The dist-upgrader can easily fallback to the text-frontend if gtk fails.

But we are late in the game...

On Fri, Oct 06, 2006 at 03:43:23AM -0000, Fabio Massimo Di Nitto wrote:
> This is going to break server upgrades since we have no such upgrader on
> them. I don't think targeting it for edgy-upgrades is the right thing to
> do and we did never had the need to run it twice before. IMHO this isn't
> nice.

That package list was surely from a desktop system.

--
 - mdz

ubuntu-minimal is installed on server too.

Fabio

On Fri, Oct 06, 2006 at 06:04:01PM -0000, Fabio Massimo Di Nitto wrote:
> ubuntu-minimal is installed on server too.

ubuntu-minimal doesn't include python-* however.

--
 - mdz

Matt i don't understand the point of cherry-picking the packages to be hounest. They are all in main and installable on server or desktop or i could have an LTSP server or whatever.. i don't think that it does really matter if it's package foo or bar here.. we are supporting them and clean upgrade from release to release+1 has always been a goal. With this situation that has been created in edgy we are breaking this rule.

Fabio

I added instructions about this to the edgy release notes.

This has been documented in the release notes. Scott thinks it's unfixable (and it probably is, now) - should this be rejected now?

(documented and not fixable any further => removing milestone)

So is there a solution for this available? Using KDE, updated via changing sources.list and update & dist-upgrade several times and hpijs won't install. All other packages are ok.

In the end I was able to sudo apt-get install hpijs and after this upgrade was ok.

Too bad if command line dist-upgrade fails, would be nice to have it working (For example KDE doesn't have a graphical upgrade tool - does it?)

r

On Fri, Oct 27, 2006 at 08:33:46AM -0000, Risto H. Kurppa wrote:
> So is there a solution for this available? Using KDE, updated via
> changing sources.list and update & dist-upgrade several times and hpijs
> won't install. All other packages are ok.

Different problem.

--
 - mdz

I had similar problems, after running apt-get -f install seems to fixed most problems. You might want to try using aptitude, this seems to have worked with the hpijs package.

This is not a problem with upstart; it's just an APT problem, it's noting the Essential tag of the installed version of sysvinit, and not noting it's been removed in the available version.

I read on a forum post (http://www.ubuntuforums.org/showthread.php?t=228788) to use aptitude instead of update manager or apt-get because it handles dependencies better. I ran dist-upgrade twice to get the new upstart package (as well as others), but after that I got the EXACT same packages being kept back. After figuring out how to use aptitude, those packages have been fixed.

My advice: try aptitude.

On Tue, Nov 07, 2006 at 06:19:24PM -0000, Jason wrote:
> I read on a forum post
> (http://www.ubuntuforums.org/showthread.php?t=228788) to use aptitude
> instead of update manager or apt-get because it handles dependencies
> better. I ran dist-upgrade twice to get the new upstart package (as
> well as others), but after that I got the EXACT same packages being kept
> back. After figuring out how to use aptitude, those packages have been
> fixed.
>
> My advice: try aptitude.

update-manager should be preferred for upgrading to the next release.

--
 - mdz

Matt,

I agree that update-manager is the preferred method for upgrading, but a LOT of people have had issues with this. I apologize for posting my advice on a bug report - this discussion should be used for fixing the problem instead of figuring out workarounds.

Regards,
Jason

On Tue, Nov 07, 2006 at 07:39:58PM -0000, Jason wrote:
> I agree that update-manager is the preferred method for upgrading, but a
> LOT of people have had issues with this.

A lot of people have had good experiences as well; if you had a problem,
please file a bug report on update-manager with complete details as these
need to be fixed.

--
 - mdz

This is fixed with a adjustment how the problem resolver works in 0.6.46.4ubuntu4.

Cheers,
 Michael

Let me be more clear: the issue that python packages are held back should be fixed, not the upstart is held-back because of its essentialness.

On Tue, Dec 19, 2006 at 09:16:37AM -0000, Michael Vogt wrote:
> Let me be more clear: the issue that python packages are held back
> should be fixed, not the upstart is held-back because of its
> essentialness.

Agreed; please file a separate bug about that.

--
 - mdz