2010/4/28 Toni Mueller <supp...@oeko.net>: > On Wed, 28.04.2010 at 21:14:52 +0200, David Kalnischkies > <kalnischkies+deb...@gmail.com> wrote: >> 2010/4/28 Matt Taggart <tagg...@debian.org>: >> > 2) diffutils and dash are "Priority: required"/"Essential: yes" in >> > unstable, but weren't in lenny. >> Every time we talk about the "problem" outlined here it boils down to: >> Why the user still have the (old)stable repository in his sources? > > this is easy to answer: Some people, like me, run a mostly stable > system, but need a few bits from up to unstable, ***NOT*** the other > way round, as you suggest.
Sorry if this sounded rude - it wasn't meant that way. I had a conversion with Matt Taggart on the IRC before and it seems i interpreted it later in the way the "problem" is normally raised: "I have upgraded from oldstable to stable and can't remove old-essentials." My bad. >> If (s)he has no package left from this old archive it is as obsolete as the >> now obsolete transition packages (s)he want to remove. > > We're talking about stable, not oldstable, here. So please calm down > instead of flaming users for running "obsolete" stuff. Also, the > package handling should be easy enough for users who are not deities > themselves. I really hope that not everyone is a deity who is able to handle packages as this would at least in my culture mean that we have only a single person/deity with this ability. ;) It is exactly my point that the user shouldn't worry about dependencies and essentials are a special case of dependencies. I am mostly confronted with the situation i described above with the obsolete (for their setup) archives so i referred to this situation - as i said in this situation no package is left, so the archive is really obsolete and can be removed from the sources, which leads also to the point the old essentials are not longer consider as old essentials. But your case of mostly stable with a few unstable packages has obviously nothing to do with obsolete archives. It is only that in this case the message is even more correct as your unstable packages could depend on an essential from unstable which is not in stable - or not with this name and/or functionality. So apt chooses the paranoid way and consider old, new and current essentials as essentials so the user doesn't run into problems (s)he would maybe face otherwise. It is therefore meant as a simplification as i guess nobody really want to check for every new package if it included implicit dependencies on an essential package… (in your case dash for example) >> If the user don't want to see it (s)he can e.g. put the not installed >> package on hold and will be done with it? > > This does not seem to work in all cases. I've recently struggled with a > system that was trying to remove or upgrade packages that I had > explicitly set on hold immediately before. But I made no recordings, > so... At least for apt this should not happen: A dpkg hold can only be overridden by the user with a direct install request (or the > 1000 pinning). aptitude uses his own hold mechanism and is not as strict, so you have maybe mixed the two? If you can find some records or encounter it again, i would be happy if you could report it. Best regards, David Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
