On Sun, Mar 21, 2010 at 02:02:19PM +0100, Santiago Vila wrote: > On Sun, 21 Mar 2010, Julian Andres Klode wrote: > > > > No, you are drawing conclusions that are not in policy. apt-get > > > would not violate policy, because policy does not say that apt-get > > > should try to "fix" the system. > > It only tries it in dist-upgrade or when installing new packages; > > and not on upgrade. > > Ok, that's a lot better than doing it unconditionally, but still not > enough as it's second-guessing the user wishes. > > > And thus it's not fixing the system; but just ensuring > > that everything needed is there before doing distribution upgrades or > > new installations. > > I would not mind if apt-get did that after a simple Yes/No question, > even if the default is Yes, for example: > > The following essential and required packages will be installed: > foo > Do you want to continue [Y/n]? > > > But apt-get does nothing of the sort, so, yes, it's "fixing" the system, > and it's overriding the user decision to remove an essential package > with dpkg --force-remove-essential. > > I agree that "fixing" the system may sometimes be a good thing, my > point is that it should not be forced and it should not necessarily be > the default behaviour. > > > Otherwise, changing the essential package set would > > be a much more difficult thing. > > No, that's not true, and I wrote specifically about this case in the > initial message for this bug report. > > The truth is that it has never been a difficult thing: > > Whenever new essential packages have been added to the system, a > dependency on an already essential and required package has been > always added. Normally, the package which has a closer functionality > to that of the new essential and required package is chosen to carry > the dependency. If no package is particularly suitable for this, > base-files could be used as a last resort. AFAIK, something like this is not required. > Conversely, when we want to drop (not add) an essential package, we > make it a dummy package first, for one release, like "mktemp" in squeeze. > > Ironically, what apt-get does in practice regarding the essential > package set is to make it really tricky to change it, i.e. the > opposite of what you said. See Bug #544481 for example, where the user > wants to get rid of diff, no longer essential in squeeze. He can't > because apt-get insist on considering diff as an essential package. Bug #544481 is a completely different bug; namely that packages are flagged essential instead of specific package versions. In my opinion, that one is a real bug; and apt should just allow to remove diff (although it would then reinstall it again; unless it is pinned to -1). > > > Keeping the integrity of the system might be a desirable and nice > > > thing in some cases, but it's not something that should be done > > > *against* the will of the user! > > > > You can prevent the installation of new essential packages by > > pinning them to -1: > > > > Package: test-essential > > Pin: version 0.0-0 > > Pin-Priority: -1 > > That is better than nothing, but does not solve the problem. The user > who has already used dpkg --force-remove-essential should not have to > do that. Well, if you force dpkg to remove it, you can also just force APT to not re-install it again. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.
Attachment:
pgpg1eJU8f3SW.pgp
Description: PGP signature