David R. Litwin wrote: > > Errors were encountered while processing: > > /var/cache/apt/archives/kdeedu-data_4%3a3.3.2-3_all.deb > > /var/cache/apt/archives/konq-plugins_4%3a3.3.2-4_i386.deb > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > I think the problem is here: konq-plugins_4%3a3.3.2-4_i386.deb > > specifically, the percentage sign. I have never seen that before.
The %3a is an html URL encoded ':' character. It means the package has an epoc in the version number. The version is really 4:3.3.2-4 and the colon is escaped. This won't be your problem. The filename in your cache is encoded to avoid name collisions with other versions with a different epoc. But in the main archive the name will not include the epoc and the collision will be avoided by the ftpmaster. > I could really use some help with this. I've tried much. Apt-get > simply will not download and installing any thing until this is > cleared up. Later you said: > I think I actually know what the problem is: Debian Sarge is telling > apt-get (or aptitude) to install these two packages: kdeedu-data and > konq-plugins. However, both of these packages have been replaced (by > kdebase-data and kdelibs-data respectively). So, what I really need to > do is tell either apt-get or aptitude to stop trying to install them: > they will not work because they have been replaced. The KDE packages have a complex set of dependencies. I often see APT confused such as you are seeing in trying to transition from one bundle of packages to the next KDE bundle. A short time ago I posted the following note to the debian-kde list. And it generated some strong disagreement from at least one person who responded. http://lists.debian.org/debian-kde/2005/07/msg00024.html But I think the advice I gave there I would give again here. Because APT is finding a different solution than the one you want I would lead it carefully through the process of getting from one to the other. Because it is so easy to install and remove software I would remove the existing problem packages and simplify the problem for APT. Then install the new packages from the new depot. I always do KDE upgrades from a text console. Because I am going to be replacing KDE and don't want to be running it at the time. However I would probably modify those previous instructions somewhat. Especially in your case where you have a mixed set of versions it will not apply directly to you. KDEVER=$(dpkg --status kdelibs4 | awk '/^Version:/{print$2}') grep-status -F Version $KDEVER | grep-dctrl -F Status -s Package -n -r "^install" That will return a list of installed packages that match the present version number of kdelibs4. Normally all of KDE would have the same version. In your particular case because you have partially upgraded they won't all be the same. You would want to find the version number of the old packages that you had installed previously that you now want upgraded. I save that to "file-listing-pkgs-to-remove" to be used with dpkg manually. I manually remove the packages that I know I want upgraded. In extreme cases, and that is what we are talking about here, I remove the previous packages with 'dpkg --purge --force-depends packagename' and then run 'apt-get install -f' to install any now missing dependencies from the new depot. Then 'apt-get install kde' the new KDE from the new depot. Because I removed the problem packages APT is no longer confused by them and can proceed with a normal upgrade and install. dpkg --purge --force-depends $(<file-listing-pkgs-to-remove) WARNING: Using 'dpkg --force-depends' will almost certainly break the dependency tree of your system. That is the purpose of that command. It is like saying that a step in replacing a hot water heater is to cut the water pipes going into and out it so that it may be removed and replaced. Cutting the water pipes breaks the plumbing of your house. That sounds bad when stated like that. But this is okay if you are going to replace the water heater and then reconnect the pipes. Just don't leave the pipes disconnected before turning the water back on! In the same way breaking the dependency system like this is okay if you are using it to help push APT into a different stable state with the new depot. But understand that it is manually unconnecting the dependency tree and the system should not be left in that broken state. Disconnect things briefly and then reconnect them by installing the new packages and get the system into the next stable and happy dependency connected state. I am assuming that all of the packages in the new depot are in a consistent state. If they are not then removing the previous packages will still not solve the problem if the new packages are not all in a consistent state. In fact if you remove the current packages and find the new depot is in an inconsistent state then you won't be able to install the new packages. In those cases you may need to lead the system back to the last stable released set and wait for the new development depot to progress a while. Bob
signature.asc
Description: Digital signature
