Your message dated Sun, 3 Jan 2016 02:19:13 +0000
with message-id <[email protected]>
and subject line Re: Bug#248443: aptitude: Incorrectly marks legit
configuration as broken
has caused the Debian Bug report #248443,
regarding aptitude: Incorrectly marks legit configuration as broken
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
248443: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248443
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: aptitude
Version: 0.2.14.1-2
Severity: normal
I originally installed exim4 and exim-daemon-light, then later on I
decided to switch to remove exim4-daemon-light and install
exim4-daemon-heavy (which I did via aptitude). However, now when I
start aptitude, it reports:
aptitude 0.2.14.1 #Broken: 3 Will use 614kB of disk space DL
Size: 772kB
If I hit "g" at this point, it says:
--\ Packages being automatically installed to satisfy dependencies
piA exim4-daemon-light <none> 4.33-1
--\ Packages to be removed
id exim4-daemon-heavy 4.33-1 4.33-1
If I select "exim4-daemon-light" it reports:
* exim4 depends on exim4-daemon-light | exim4-daemon-heavy |
exim4-daemon-custom
As far as I can tell, I've got a valid configuration since exim4
depends on exim4-daemon-heavy, and I have it installed. But no matter
what I do, it always complains that it's a broken dependency. So
every time I install something using aptitude I have to manually hit
"+" on exim4-daemon-heavy and "-" on exim4-daemon-light to reinforce
the current state, otherwise it'll swap them back.
This could be a problem with the exim4* packages, but I wasn't sure,
and dselect doesn't report the same problem so I'm guessing that it's
an issue with aptitude. What else can I do to help diagnose the
problem? Thanks.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-1-686-smp
Locale: LANG=C, LC_CTYPE=C
Versions of packages aptitude depends on:
ii apt [libapt-pkg-libc6.3-5-3 0.5.25 Advanced front-end for dpkg
ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an
ii libgcc1 1:3.3.3-7 GCC support library
ii libncurses5 5.4-3 Shared libraries for terminal hand
ii libsigc++-1.2-5c102 1.2.5-1 Type-safe Signal Framework for C++
ii libstdc++5 1:3.3.3-7 The GNU Standard C++ Library v3
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi Bharat,
2004-05-13 05:59 Bharat Mediratta:
Daniel Burrows wrote:
Hm, so exim4 and friends are still listed as broken after you deselect
exim? Can you see what's causing that? (since it can't be exim
anymore)
I was unclear earlier. After I deselected exim, there were no more
broken packages, but it still wanted to flip flop the light and heavy
daemons.
Ok, I've figured out how to trigger the behaviour. You are correct
that the issue revolved around the exim package. Here's how to
reproduce the problem:
Install exim4, exim4-base, exim4-config and exim4-daemon-heavy. Quit
aptitude. Restart aptitude and mark the exim package for install.
Quit aptitude again. Restart aptitude and it will report that there
are 3 broken packages (exim4, exim4-base, exim4-config). Hit "g" and
it will try to uninstall exim4-daemon-heavy and install
exim4-daemon-light.
I tried to reproduce this, but there's no "exim" package nowadays.
2004-05-13 15:54 Daniel Burrows:
The problem as I see it is that once you're in this state, there's no
easy way to see that the root cause of the problem is that the exim
package is marked for install without paging through all package lists
to find the hidden one marked for install. If I hit "g", it doesn't
list exim as a package to be installed.
Without more information from the apt backend, I'm not sure I can
detect this case -- the problem package (exim) isn't going to be
installed any more, so there's no reason to suspect its involvement in
the automatic changes. aptitude basically looks at the current package
states and tries to guess why apt did what it did, but I didn't
anticipate stuff like this and I'm not sure I can detect it easily.
Ccing the deity list to see if they have additional comments.
Now at this point, if you quit and restart aptitude and find the exim
package, it's marked as "pi". Deselect it, hit + on exim-daemon-heavy
and - on exim-daemon-light, quit and restart aptitude, then all is
normal. However, if you hit "g" first (but don't go through with the
install) then find the exim package it's simply marked as "p" and so you
can't uninstall it. In that scenario, I found I had to hit + then - on
exim and then fix the two daemon packages before everything returns to
normal.
Yes, something funny is going on with saving package state.
More than a decade later, without any more input or secondings to this
bug and with heavy changes and refurbishing of aptitude internals and
many changes in apt, I expect that the underlying problem has been
ironed out without this bug being closed...
So I am going to close this bug report now, sorry that it was not
handled in a timely manner.
If somebody still sees similar problems, please submit a new report, it
would be easier to track the underlying problem without the baggage.
Cheers.
--
Manuel A. Fernandez Montecelo <[email protected]>
--- End Message ---
_______________________________________________
Aptitude-devel mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
