I went to remove some unused packages this afternoon - they were part of a metapackage I installed a while ago that I could never get to work; it had some missing, some broken pieces. I had pretty much forgotten about them as they hadn't caused problems up until today, when PackageManager applied some updates for a few of them, it triggered a configuration script.

I'm in some sort of Catch-22: if I try to remove any of them the removal script dies in about the same way the install script did. But in order to update anything else, I have to put the packages back on my system, broken; if I don't, PackageManager will keep telling me:

"It is impossible to install or remove any software. Please use the package manager "Synaptic" or run "sudo apt-get install -f".

When I do that, it puts the non-working components back on but then the install script bombs again; basically, it ends up just like it did in the first place:

It seems your database installation went well and smoothly. That's cool.
Please enjoy using GForge.
ERROR -

About the best I can seem to do is to leave parts of it in a partially there, partially gone state:

I've tried dpkg -r && dpkg -P w --force-all; didn't work.

Is there any way to tell dpkg to just get rid of as much of the thing as it can, remove the entry from the db of installed pkgs, and forget about it?

Thanks,
Larry

so this is on an Ubuntu box of some version or other ?

If you're not going to add your distro to your profile the least you could do is list it in the post when you are requesting help ....

Gahhh... I sincerely appologize for that; I know how irritating "my computer is broken; it locks up. a lot. plz help." posts are; from the looks of it, when I went to clean up my post before I posted it, I deleted the wrong part.

I didn't fill out anything in the profile as I'm working with several versions of several distributions; it wouldn't have served do much except help confuse the issue even further. The reason for that is work-related, not that I'm trying to drive myself insane (though it does seem to be having that effect).

At any rate, this particular one is Debian "etch" (4.0), apt == 0.6.46.4-0.1 && dpkg == 1.13.25. Sorry, again, for the omission of that the first time around.

Again, what I'm looking to do is get several packages out of the list of packages that are updated; at this point, I don't really care if they're automatically cleaned up after or not. I thought there was a way to do that with dselect but I couldn't find it.

From what I can gather, there isn't any obvious mechanism for doing what I'm trying to do for several reasons, not the least of which being that problems of this nature aren't supposed to occur. And they usually don't; this is actually the first occasion I've had to need to do something like this w apt / dpkg. In comparision, problems with RPM aren't too uncommon; we've had enough problems with RPM to warrant the development of in-house tools that can examine, repair, manipulate, etc. the RPM db.

All of that said, if anyone has any suggestions to offer with respect to how to (or how not to) deal with this, I'd greatly appreciate it.

Again, please accept my sincerest aplogies regarding the lack of specificity in my earlier post; it was completely unintentional.

- Larry

In the Debian forum one can usually assume Debian

But yes, always stating your distro and its version is good practice.

dpkg has a cachefile with the various installed packages. Remove that, rebuild the database with aptitude keepall and try again. Probably /var/cache/apt, but have a look around to be sure (include tha man-pages). Can't be more specific, time to get to work.

did you try deborphan?.....not really sure if this is what you need but it cannot hurt and give a list of orphaned files that you can decide to delete manually.

[QUOTE=Dutch Master;2885481]dpkg has a cachefile with the various installed packages. Remove that, rebuild the database with aptitude keepall and try again.]
That just reset the status flags on all installed packages; according to the aptitude man page, that seems to be what it's supposed to do:
In looking around at the various files that apt, dpkg, etc. use, I'm not completely clear on what does what - the same info seems to be in more than one place, in some instances.

The one that stands out is /var/lib/dpkg/status; it's a flat file, but it is a complete list of packages on the system and what they're flagged as. In principle, what I want to do is remove a few packages from that list. I don't care if the packages uninstall / clean up after themselves; I can do at least the bulk of that manually. I just want to get things to a point where apt, dpkg, etc. don't think those packages are installed now or ever were.

I seriously doubt that I'd do much but trash the apt / dpkg if I went and manually edited /var/lib/dpkg/status, though. Still, it would seem that there would have to be some way to do that...

There are a number of files in /var/lib/apt/lists that play into the picture here, too; after looking at them & from "man apt-cache", and from having used apt-cahce --policy, I'm beginning to think "the cache" isn't kept so much as it's generated each time it's needed "on the fly", and I'm wondering if that's true for the other apps as well.

Thanks for your time; hope you made it...

Deorphan is a handy tool but it doesn't look like it's going to do what I need it to; I seem to be needing something more along the lines of "debassassinate".

There has to be some way to do this... The way things are going I'm going to have to wait until working verions of the packages that are broken are released, and "upgrade" to them, so I can remove them... That would be a pain in the neck...

- Larry

lol.....i like your choice of words.....i will have to remember that...lol

Have you tried to install, then reinstall without removing in between?

Post the output of:
/var/lib/dpkg/info/gforge-ldap-openldap.prerm
and
/var/lib/dpkg/info/gforge-ldap-openldap.postrm
if someone would spot a fault in the install/uninstall scripts.
You could also try commenting out the "-e" or the line "set -e" and see if you can remove the package.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=429750

Yeah, but that didn't do it either; the LDAP meta-package they're a part of is fundamentally FUBAR. Unfortunately. I've got a different one working in it's place but will revisit that @ some pt as IMO it's very nice...
slapd + postgres makes for a powerful combo, when it works ;(

Thanks; you confirmed what I thought to be the case - eg., that the only way I was going to get it out of there was to "convince" the software installer that it'd been properly removed. Changing the she-bang from 'sh -e' to just 'sh' ('s/sh -e/sh/') && commenting out the "set -e" stmts along with a little shell script hacking did the trick; that's correct for a package that was installed but was (P)urged and is now (N)ot installed, right?
Assuming that's correct, I've just got to remove any left-over files, etc. ; that's the least of my worries, though.

Thanks, everyone, for your help; I had been reluctant to mess with it to that extent until I heard from someone(s) who knew what they were doing.

- Larry

My initial thought was he had Debian but in his post he said 'sudo apt-get install' which is more Ubuntu-eze. Which is why I requested the clarification. I mean depending on the distro it could have been a known bug... who knows ?

How so?

Because Debian doesn't use sudo. You'd have to explicitely enable it for Debian to use it instead of (more like: as an addition to) the su command.

.. you're right, I forgot that. One of the first things I do on my Debians is give my regular account full sudo access, so I forgot it wasn't default.

AFAICT the package is gone. You can check for left-overs and do a "dpkg -P gforge-ldap-openldap" followed by "dpkg --configure -a" just to be sure.

As for the discussion about distro, he did have in his first post:
If he has trouble with a package, one might assume that people at least look which package he is talking about. But yes, mentioning the distro used is preferable.