2010/3/21 Santiago Vila <sanv...@unex.es>: > This is a bug because, for example, once you upgrade an essential > package like the real diff to a non-essential one like the dummy diff, > the old essential package should not be considered essential anymore, > even if it's available, i.e. it is the *currently* installed packages > the ones that decide which packages are essential, not the old available > ones, but for the same reason, not the *new* available ones either > (which is what I am complaining about). And in which way apt should know that you no longer have a package from e.g. stable which requires the functionality of package X which is in testing no longer essential? The closest match is that if you removed the sources for stable you have fully upgraded to testing.
Consider a case in which an essential flag is dropped without an replacement - e.g. then perl-base is no longer required to be essential. If you have multiple sources you most likely have also packages from multiple releases - so some older packages maybe depend implicitly on perl-base, you can't tell me which packages does this, can you? (And yes, i still think it is silly that users want to remove obsolete packages but don't want to remove obsolete sources list entries…) > This is the reason policy says that an essential package should not be > removed easily but it does not say that all essential packages should > be installed automatically. I would be really interested in the difference. If you haven't removed it, why apt wants to reinstall it then? dpkg also allows you to install a package and ignore its dependencies, so apt shouldn't try to fix this? The job of APT is to prevent the user from dependency hell, essentials are here to prevent the archive from too many dependencies. If APT would stop taking care of dependencies - and essentials are the hardest form of dependencies (They are always installed, will never be removed and work even in unpack state.) - the sole idea behind APT is destroyed… What you could try with your package is Provide+Conflict+Replaces the essential package - apt will not come up with a solution to this "problem" itself as we will have a (short) time frame in the transition in which no package is installed providing the functionality so you still have to go over dpkg force flags, but at least in theory apt should notice with the provides that a package with this functionality is installed after that. Another thing you can try is installing a dummy package with this name and an exorbitant high version number… … or you can wait until the next release. It should include a way to disable essentials completely or limit them to installed packages. [0] I think both modes are silly in general but i needed them sometimes for debugging multiarch and i guess they will find their users - i just hope these users are then clever enough to do the job i would never ever want to do again on my own - i have a package manager for dependency solving… Best regards / Mit freundlichen Grüßen, David Kalnischkies P.S.: After all, we are talking here about ~25 packages -- i accept bets now then the bugcount talking about essential packages exceeds the actual count of packages marked as essential… [0] http://bazaar.launchpad.net/~donkult/apt/sid/revision/1972 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
