[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#535967: Inconsistent state after removal.


Am Dienstag, den 07.07.2009, 16:40 +0300 schrieb Kari Pahula:
> On Tue, Jul 07, 2009 at 02:21:44PM +0200, Joachim Breitner wrote:
> > Kaol, can you comment on the ghc-pkg behaviour? Is "--force" the right
> > thing to do, or is there an alternative?
> Did you try --no-user-package-conf yet? 

Ah, that’s the option. I knew I saw something like that. I’s not
mentioned by ghc-pkg(1), though. That would be better than force, if it
works, I’d say.

> Other than that, something
> like "HOME=/ ghc-pkg ..." should work, even if that's an ugly hack.
> I'm not sure if ignoring ghc-pkg unregister's error or using --force
> is that good an idea.  There's global user installed Cabal packages to
> consider (inadvisable as those may be).  I'd rather expect users to
> unregister those first by themselves with ghc-pkg.  After all, they're
> there because they installed them by themselves with ghc-pkg, in the
> first place.

Note that we had some severe problems about a year ago when prerm _did_
fail when ghc-pkg failed: When something was broken inside the Debian
packages somewhere, people will have huge problems getting rid of them –
including the buildds. Therefore, I think we do not have to abort a
package removal if it breaks site-install packages.

Additional rationale: If the user builds a binary from source himself,
or writes a perl script, nothing stops dpkg from removing their
dependencies either. It’s the responsibility of the admin not to touch
the dependencies (or use equivs or such).


Joachim "nomeata" Breitner
Debian Developer
  nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Attachment: signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil

Reply to: