Michael Vogt writes ("[Bug 54234] Re: update-manager for edgy needs to upgrade dpkg early on"):
> The problem is essentially the same, i.e. the libapt implementation that
> calculates the upgrade from dapper->edgy will not know about breaks
> (yet). Downloading/install dpkg early does not help here because libapt
> needs some understanding about the field as well. Upgrading dpkg/apt and
> then re-runing the dist-upgrader to calculate a new upgrade would work
> but it makes the operation irreversible (well, we could DOWNGRADE again
> *shudder*) - something that we don't really want.
So as I understand it, the problem is that the dist-upgrader wants to
calculate in advance what it's going to do, before giving the user the
chance to say yes/no ? And you can't calculate correctly with the old
apt.
How about unpacking the new apt somewhere and running it with
LD_PRELOAD et al to calculate the upgrade ?
Michael Vogt writes ("[Bug 54234] Re: update-manager for edgy needs to upgrade dpkg early on"):
> The problem is essentially the same, i.e. the libapt implementation that
> calculates the upgrade from dapper->edgy will not know about breaks
> (yet). Downloading/install dpkg early does not help here because libapt
> needs some understanding about the field as well. Upgrading dpkg/apt and
> then re-runing the dist-upgrader to calculate a new upgrade would work
> but it makes the operation irreversible (well, we could DOWNGRADE again
> *shudder*) - something that we don't really want.
So as I understand it, the problem is that the dist-upgrader wants to
calculate in advance what it's going to do, before giving the user the
chance to say yes/no ? And you can't calculate correctly with the old
apt.
How about unpacking the new apt somewhere and running it with
LD_PRELOAD et al to calculate the upgrade ?
Ian.