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

Bug#544481: Bug#557209: Bug#544481: apticron: apt-get dist-upgrade pulling required packages from unstable



2010/4/28 Toni Mueller <support@oeko.net>:
> On Wed, 28.04.2010 at 21:14:52 +0200, David Kalnischkies <kalnischkies+debian@gmail.com> wrote:
>> 2010/4/28 Matt Taggart <taggart@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



Reply to: