Bug#76219: apt: apt-get dist-upgrade is too agressive in removing packages
On Sun, Nov 05, 2000 at 12:01:40PM +0100, Christian Kurz wrote:
> On 00-11-04 Kurt D. Starsinic wrote:
> > On Sat, Nov 04, 2000 at 04:24:19PM +0100, Christian Kurz wrote:
> > > On 00-11-03 kstar@sri.net wrote:
> > > > Package: apt
> > > > Version: 0.3.19
> > > > Severity: normal
> > >
> > > > This just seems wrong to me:
> > >
> > > > % apt-get -s dist-upgrade
> > > > Reading Package Lists...
> > > > Building Dependency Tree...
> > > > The following packages will be REMOVED:
> > > > xcontrib xcopilot xmanpages xpm4g
> > > > The following NEW packages will be installed:
> > > > libxaw-dev libxaw6 libxaw7 xlibs xlibs-dev xutils
> > > > The following packages have been kept back
> > > > task-x-window-system-core
> > >
> > > Would you please explain what's wrong about this and why especially you
> > > report this as bug against apt?
>
> > If I took this upgrade, I would lose xcopilot (because of a dependency
> > on xpm4g). Shouldn't apt keep all of these back until there's a version
> > of xcopilot available that doesn't depend on xpm4g? That's what I've grown
> > to expect, and what I would want.
>
> How should apt be able to do this. I tries to resolve all dependencies
> and does only stop when there a certain dependency problems. I think it
> would be the wrong way to patch apt to handle such a problem. Those
> problems occur because you use unstable, where currently a big upgrade
> to Xfree4 is going on. So to force apt to handle such problems is the
> wrong way. If you use unstable you should always be aware, that such a
> problem mayb occur especially if there's just a big X-Update going on.
> Look at the dependencies of the packages that should be removed and you
> should be able to see why it would have been. I think apt is handling
> the situation exactly as it should be.
Christian,
I am happy to deal with _any_ problems that come with unstable -- I
know what I am getting into.
I believe that apt should and could do something different in this
case. apt is able to hold back upgrades on certain packages, and because
xcopilot is selected and no package listed above replaces: or provides:
xcopilot, the X upgrade should (IMHO) be held back until there is a version
of xcopilot that doesn't depend on xpm4g. In fact, I will do this manually
by not taking a dist-upgrade until I don't lose xcopilot.
I don't want to be a pain, but as I said, I observe that there are
cases when apt _does_ hold back an upgrade until it can avoid removing
selected packages. If there is something unusual about this circumstance,
I would be grateful if you could point out what it is.
- Kurt
Reply to: