Bug#183702: confirmation + apt-get dist-upgrade debug output
On Wed, Jan 07, 2004 at 12:09:09PM -0800, Matt Zimmerman wrote:
> depend on kdelibs3 can remain on the system. Note that this completely
> defeats the purpose of separating shared libraries, which is to allow smooth
> upgrades, so I hope there was a good reason for adding this conflict.
I have not verified tthis personally, but according to upstream, there
is little chance any kde2 application will work with the
updated data files kde3 brings to the system. Technically it should
enough if just kdelibs-data conflicted with kdelibs3, so this conflict
is superfluous.
> Another problem is with the metapackages, most of which are simply
> uninstallable in unstable. kde depends on kde-core, which depensd on
> kdelibs, which does not exist. This is why the 'kde' metapackage is being
> removed.
kdelibs does definetly exist on sid. apt-get install kde appears also
functional.
> The rest of the breakage seems to be the result of hundreds more versioned
> conflicts which seriously complicate the upgrade.
Most of these are because files have moved around from package to
another at the time of major upstream upgrade. Replacing a kde2 package
partially with files from a kde3 package will most definatly result an
unusable system.
I guess that they are unneeded too, as installing the kde3 app will not
be possible without installing kdelibs4 (and thus) kdelibs-data?
> > I think what should be done is to add a dummy kdelibs3 package which
> > depends on kdelibs4, but I do not have enough apt expertise to be
> > certain. Anyone who knows more ?
> That could help, since many conflicts would be removed and replaced by
> dependencies on dummy packages.
In that case, we would still need to make sure that after installing the
dummy kdelibs3 no apps depending on the real kdelibs3 would be installed
anymore?
--
Riku Voipio | riku.voipio@iki.fi |
kirkkonummentie 33 | +358 40 8476974 --+--
02140 Espoo | |
dark> A bad analogy is like leaky screwdriver |
Reply to: