Nelson A. de Oliveira wrote: > Steps that I do to reproduce this error is: > > - orphaner -a > - Go to "cdw" > - Select it > - OK > - It exits with E: Couldn't find package "cdw"
I tried to reproduce it on Sid (dpkg was not up to date, but this should not make a difference) and failed. > orphaner is failing with 'E: Couldn't find package "cdw"' here. This is an apt-get error message, it also occurrs when you try to remove a non-existing package. It is thrown in by DoInstalll(CommandLine &CmdL) in apt-get.cc (two occurrences in the same function). orphaner is a shell script which mainly calls dialog, deborphan and apt-get. This is how orphaner calls apt: | set -e | APT_GET_ERROR=$(gettext '"apt-get" returned with exitcode %s.')'\n' | NUMBER_OF_PACKAGES_ERROR=$(gettext '"apt-get" tries to remove more packages than requested by orphaner. Exiting.')'\n' | APT_GET_CMDLN="apt-get $PURGE --show-upgraded --assume-yes remove $PACKAGES_TO_REMOVE" | if apt-get check -q -q; then | LC_ALL=C $APT_GET_CMDLN --simulate \ | | grep -q "^0 upgraded, 0 newly installed, `echo "$PACKAGES_TO_REMOVE" | wc -w` to remove and" | if [ $? -ne 0 ]; then | LC_ALL=C $APT_GET_CMDLN --simulate >&2 | printf '%s\n' "$NUMBER_OF_PACKAGES_ERROR" >&2 | exit 1 | fi | $APT_GET_CMDLN || ERROR=$? | else | printf '%s\n' "$APT_GET_LOCKFAIL" >&2 | printf '%s\n' "$APT_GET_CMDLN" >&2 | exit 1 | fi | unset APT_GET_CMDLN PACKAGES_TO_REMOVE | if [ $ERROR -ne 0 ]; then | printf "$APT_GET_ERROR" $ERROR >&2 | exit 1 | fi The code above calls apt-get check but this does probably not cause this error. It also calls $APT_GET_CMDLN --simulate silently and then visibly if the number of to be removed packages is not equal to the number orphaner requested to be removed and apt-get did exit with 0 (set -e causes the latter). If the number of packages does match it calls $APT_GET_CMDLN without the option --simulate. Removing set -e in line 28 could help to determine which apt-get call causes this error but I don't think that this would help since they are quite similar. All it does in your case is running the following command, with or without --simulate: > $ LC_ALL=C apt-get --show-upgraded --assume-yes remove cdw --simulate > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following packages will be REMOVED: > cdw > 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. > Remv cdw [0.3.3-2] ... and, as we can see, it works on your system. I have no idea why it does not work when it is run by orphaner instead of a shell in your case. Further steps to reproduce and fix this bug would require to read DoInstall(...) in apt-get.cc to understand what apt-get exactly does to determine that a package is not findable. It would probably also require more files which are used by apt-get or dpkg to be sent by mail, e.g. /var/lib/dpkg/available and /var/lib/apt/lists/*. Honestly speaking, I don't think it is a bug in deborphan but instead in apt or in your installation and I also do not think that reproducing this bug is worth the effort to read and understand apt-get's source code and send half of your systems files per mail. I will tag this bug as unreproducible and lower its severity in a few days unless you got a better idea. I guess you are sure you did not use orphaner's option -f, which could cause such a behaviour, e.g. if the status file is from Sid and the system orphaner runs on is Etch. A workaround for you is running orphaner as unprivileged user and then run the printed apt-get command line as root, you could also run deborphan directly. Regards, Carsten -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
