Bug Stamp Out List
Hello,
this is my first posting of a complete record of my bug report analyzing.
You will easily see how I work. This is not the first time I do it, I did it
for libc6, too. New is the Summary Information section. It is only to be
considered as a guideline. For example, if you are annoyed at the many open
bug reports, take the "Actions to take:", "Close:" entries and process them.
This could be done very fast, as it only requires verification of what I
done (assuming I did my job well, you can just close these reports).
Here is a short explanation of my categories, but they are choosen ad hoc,
and you may want to skip it.
"Patch+Close:" means, a patch is available for the problem. If you like the
patch or not is a different question...
"Fix+Close:" means, the bug report can be fixed by a changing a bit in the
code, or adding some lines. All of these reports should not be too hard to
fix, and interested people can take them as an exercise to become familiar
with dpkg and friends (submitting a patch, see above).
"Decide(+Close):" Needs a technical or policy decision to be made by the
maintainer one way or the other. Depending on the decision, the report moves
into another category or can be closed.
"Investigate:" means that I couldn't figure out if this report is relevant
or not. Somebody else needs to submit information. But I tried as good as I
could.
"Discuss:" Those are the hard ones. Core dpkg developers will have fun for
months with these.
I hope you find this information helpful. It would be great if you could
process the easy ones fast, so we can move on to the important issues. I
will just continue at my own pace to add entries to this list, and update
existing entries, but if this list is only growing, it does not expose its
full usefullness (entries will be removed when a bug is closed for some
time).
Any suggestions are welcome. If you have fun writing diagnostic scripts, be
welcome to use this as a base. I am willing to include more diagnostical
information in these report, like date of submissions etc, if it is helpful.
My first impression is that about 40% - 50% of the current open bugs against
dpkg can be closed in a very short time (without changes to dpkg). Some
other 20% - 30% require only small bug fixes, and 10%-15% some harder bug
fixes. Only a few will remain with important design issues for dpkg 2.0 :)
Thanks,
Marcus
Here starts the fun:
== DPKG =====================================================================
Initial release, no changes yet.
== Summary Information ======================================================
Bug reports listed below:
1399, 1642, 1818, 2531, 2828, 2863, 2904, (2973, 3125), 3218, 3233, 3704,
4074, 4195, 4379, 4393, 4419, 4450, 4468, 4801, 4901, 4974
Actions to take:
Tell Marcus what's going on here, because he is confused: 4074
Close: 3218, 1642, 2531 (?), 3233, 3704, 4393, 4450, 4419
Patch+Close: 2904, 4195
Fix+Close: 2863, 1399, 1818, 4801, 4901, 4974
Decide(+Close): (2973, 3125), 4468
Investigate: 4319, 4379
Discuss: 2828
Actions taken:
Merged: (2973, 3125) [MB 1999/3/6]
Contact Submitter: 3233 [MB 1999/3/6]
== Diagnosis ================================================================
Report: 1399
Status: Open, should be easy to fix.
Analyse: dselect bails out if "Select" is choosen while db area locked.
Explanation:
While dpkg database is locked, dselect can't operate cleanly.
However, when choosing Configuration, Installation or Removal, it does not
bail out back returns back to the main menu.
Strategy:
Make dselect return to the main menu if Select is choosen while database is
locked.
Report: 1642
Status: Open, can be closed.
Changelog: See dpkg 1.0.6
Analyse: dselect recursive dependency resolution doesn't do the right thing.
Explanation:
Raul says that dselect's recursive dependency resolution doesn't work if
recommended packages aren't available.
Strategy:
As dselect spits out messages about his today, this bug report can be
closed.
Report: 1818
Status: Open, normal.
Analyse: dpkg should base configure ordering on Recommends
Explanation:
If a package recommends another package, this other package should be
configured first if possible. (the perl example in the changelog is not
true any longer, though, I'm afraid).
Strategy:
Needs code to fix it.
Report: 2531
Status: Open, can be closed?
Analyse: install-info needs better locking strategy.
Explanation:
I am a bit puzzled here, the bug report is very short, here:
Thomas Krichel writes ("incomplete package installation"):
> Unpacking replacement emacs ...
> install-info: failed to lock dir for editing! File exists
> install-info: failed to lock dir for editing! File exists
Strategy:
Ian, if this was fixed silently, please close the report. Otherwise comment
what is wrong here. I have never seen this errornous behaviour (beside
under the Hurd, which doesn't have POSIX locking yet :)
Report: 2828
Status: Open, normal.
Analyse: dpkg does not reckognize same file with different names.
Explanation:
For example, when moving files from /usr/bin/X11/ to /usr/X11R6/bin (to fix
a bad package), dpkg will happily remove the just installed file again.
The sitation exists inside a single package (during an upgrade), and
between different packages.
Strategy:
This needs to be discussed and implemented. I think this is pretty
important and should be aimed at probably for a new major revision
of dpkg (2.0 perhaps?).
Several suggestions were made, but no convincing.
Report: 2863
Status: Open, normal.
Analyse: ncurses problems in a xterm.
Explanation: Reversed text does not reverse surrounding area.
Strategy:
When printing reversed text, for example in the help screen or the
description, make sure that the whole area is filled with reversed
spaces, too.
[btw, I couldn't reproduce problems with the blue status bar, it is correct]
Version: dpkg_1.4.1.1, libncurses4_4.2-3
Report: 2904
Status: Open, can be closed if patch is applied.
Analyse: install-info does misbehave when dir is not available.
Explanation:
The point was made that install-info just gives up when no dir file is
there, with a bad error message about file locking.
However, install-info can't really recreate the file. It was suggested that
install-info keeps a backup of the file. The following patch by Marcus
(that's me) adds this feature and has a better diagnostic.
Patch:
--- install-info.old Mon Feb 1 01:21:22 1999
+++ install-info Fri Mar 5 20:58:21 1999
@@ -27,6 +27,7 @@
$maxwidth=79;
$align=27;
$calign=29;
+$backup='/var/backups/infodir.bak';
undef $menuentry;
undef $quiet;
@@ -208,6 +209,19 @@
}
}
+if (!$nowrite && ! -e "$infodir/dir") {
+ if (-r $backup) {
+ print STDERR "$name: no file $infodir/dir, retrieving backup file $backup.\n";
+ if (system ("cp $backup $infodir/dir")) {
+ print STDERR "$name: copying $backup to $infodir/dir failed, giving up: $!\n";
+ exit 1;
+ }
+ } else {
+ print STDERR "$name: no backup file $backup available, giving up.\n";
+ exit 1;
+ }
+}
+
if (!$nowrite && !link("$infodir/dir","$infodir/dir.lock")) {
die "$name: failed to lock dir for editing! $!\n".
($! =~ m/exists/i ? "try deleting $infodir/dir.lock ?\n" : '');
@@ -339,6 +353,7 @@
rename("$infodir/dir.new","$infodir/dir") ||
&ulquit("$name: install new $infodir/dir: $!\n");
unlink("$infodir/dir.lock") || die "$name: unlock $infodir/dir: $!\n";
+system ("cp $infodir/dir $backup") && warn "$name: couldn't backup $infodir/dir in $backup: $!\n";
}
sub ulquit {
Report: (2973, 3125)
Status: Open, (can be closed). Please merge with 2973.
Changelog: See dpkg 1.2.3
Analyse: install-info adds multiple sections with same name.
Explanation:
Kim sent in a fix for this, which is already in dpkg source. No problem.
But IanJ thought it would be a good idea to fix already broken files.
So a script was written to do that (merge existing sections with same
name). This script is included in the bug log.
Strategy:
Make a decision between following two possibilities:
i) Drop the idea of fixing broken dir files. This problem is from May 1996,
and it is probably more risk to break existing good dir files with this
operation than fixing still broken ones (who has info/dir files from 1996?)
ii) Include the fixing script in dpkg and call it from dpkg postinst, in
case we are updating from an old version.
My personal favourite is i), because in the last three years the problem
has most probably vanished all by itself.
Report: 3218
Status: Open, can be closed.
Changelog: See dpkg 1.2.4
Analyse: install-info adds section in a wrong way.
Explanation:
Because of a missing newline, install-info behaved wrong. It is
unclear to me if only a \n in install-info was necessary, or also in
base-files. However, both places are fine today.
Strategy:
Close the report.
Report: 3233
Status: Open, can hopefully be closed.
Analyse: bugs in dselect of 1.1.
Explanation:
Heiko describes two bugs here, but didn't gave additional
information needed.
Strategy:
This is probably so old, that the bugs have been fixed silently in the
meantime. I contacted the submitter, and if he does not respond positively
in the next time, this bug should be closed.
Report: 3704
Status: Open, can be closed
Changelog: See dpkg 1.2.11
Analyse: dependency bug in dselect.
Explanation:
When installed version is later then available version, dselect enters the
conflict resolution screen even with no conflict.
Strategy:
As this bug was fixed in 1.2.11, the report can be closed.
Report: 4074
Status: Open, ???
Analyse: ???
Explanation:
I do not understand what the report is about. Obviously it is some personal
note from Ian to himself, and it doesn't explain the bug'ness.
Here is the complete bug log, so you don't need to look that up. Please let
me know what's happening here (only thing I can imagine is that conffiles
shouldn't be in files per package or so):
Package: dpkg
Version: 1.3.1
Scott Barker writes ("Re: problems with 1.1 release"):
...
> ok. Although, I beg to differ about the *.conffiles:
>
> ls /var/lib/dpkg/info/*.conffiles
> /var/lib/dpkg/info/adduser.conffiles
> /var/lib/dpkg/info/at.conffiles
> /var/lib/dpkg/info/base.conffiles
> [etc]
Oops, this is a bug. I'll fix it some time (it's just some wasted
space - there are no real problems with it).
Ian.
Report: 4195
Status: Open, can probably be fixed and closed.
Analyse: dpkg-source contains a hack to work with broken tar.
Explanation:
Some version of tar back in 1996 didn't understood the "--" flag, so it was
removed from dpkg-source. But Ian chose to let thereport open so he could
add it again when tar is fixed.
Strategy:
As I don't fully understood what was broken with tar, and I have no old
dpkg-source around to compare, I can just ask Ian (or someone else who
remembers to look if tar works again, and revert dpkg-source.pl (just search
for string "FIXME" in the source, it's there). After that, close the
report.
Report: 4319
Status: Open, unclear.
Analyse: dpkg does overwrite changed conffiles during upgrade
Explanation:
The claim was made that dpkg overwrote silently changed conffiles during
package upgrade, but it is not proven. It is hard to reproduce what
happened.
Strategy:
This report should probably be closed. If there was really such bug in
dpkg, it would have been noticed by many people in the meantime. Without
the original packages, we can't try to reproduce it, and the changelog from
netstd/netbase doesn't reach back this far.
Alternatively you can try to get more information from the submitter, but I
wouldn't know what to ask, so someone else has to do it.
Report: 4379
Status: Open, unclear.
Analyse: Installing a package fails because a package it depends on is not
yet installed (but "selected").
Explanation:
dpkg (started from dselect) did interrupt the installation because perl
needed libgdbm, which wasn't installed but selected.
The perl changelog tells me that perl pre-depended on libgdbm that days, so
it may be a pre dependency problem.
Strategy:
I am quite certain that pre-depends work today and do not lead to
an interrupted install, but I don't know all install methods. So you may
want to close this bug. At the very least perl does not predepend on
libgdbm today, which may also be a good answer :)
Report: 4394
Status: Open, can be closed.
Changelog: See dpkg 1.4.0.1
Analyse: Argument to $rootcommand should be quoted.
Explanation:
The argument to the $rootcommand in dpkg-buildpackage should be quoted, so
"su -c" does work with command "debian/rules build".
Strategy:
This bug was fixed in dpkg 1.4.0.1 and the report can be closed.
Report: 4419
Status: Open, can be closed.
Changelog: See dpkg 1.4.0
Analyse: debian-changelog.el should use magic subst strings
Explanation: changelog mode should use way to automaticall insert currentrr
keybindings.
Strategy:
Was fixed in 1.4.0 and can be closed.
Report: 4450
Status: Open, can be closed.
Analyse: dselect should warn about super-current packages and don't downgrade stuff.
Explanation:
The submitter says it's "scary" that dselect offers packages with lesser
available version under "up to date" packages, and is afraid of dselect
downgrading these.
Strategy:
Close the report. Scott Ellis pointed out (correctly, AFAIK), that dselect
won't downgrade packages (-G option to dpkg). Therefore this report is
uninformed and can be closed.
Report: 4468
Status: Open, normal (could probably be closed).
Analyse: dpkg should accept that new package has no postrm.
Explanation:
If a package is upgraded, and the old postrm _fails_, and there is no new
postrm, dpkg will give up.
Strategy:
Well, there are two ways to interpret this:
1) dpkg is correct. the old postrm encounters problems, and dpkg just tries
the newer postrm as a last resort, and to give the maintainer a chance
to fix a bug in a newer version of the package. If there is no postrm in
the newer package, the problem can't be resolved, and dpkg should abort
(otherwise, the package maintainer had made an empty postrm, right?).
2) dpkg is incorrect. A missing postrm in the latest package could be
interpreted as "no postrm needed" and dpkg could ignore that first postrm
broke.
I think that interpretation 2) is very wrong, and in disharmony with the
philosophy of packaging script policy. A maintainer is responsible for
upgradeability. If one postrm in one version doesn't work, he must make sure
that all later packages include a workaround in the postrm of the later
version, and the postrm with the workaround must never be removed (in this
case, the submitter removed the postrm himself).
Ian, you set the severity from fixed back to normal. Why? What is the
reason that you think dpkg's behaviour is wrong or suboptimal?
Report: 4801
Status: Open, normal.
Analyse: dselect key "I" does not work.
Explanation:
If you press I twice, so you get the minimal package list and biggest
description area, the shown package in the package list (it's only one) is
most of the time the wrong one, and scrolling keeps to be wrong.
Strategy: Fix dselect. It should be just one missing reset when I is
pressed. Somehow you need to reinitialize the package list screen.
Report: 4901
Status: Open, unchecked.
Analyse: dpkg doesn't change dir permissions, which should be documented.
Explanation:
dpkg doesn't set the permissions of directoryy according to theinformation
in the package. This is deliberately, but should be documented.
Strategy:
Check if this is documented., If no, document it, then close the report in
either case.
Report: 4974
Status: Open, normal.
Analyse: "dpkg -s blah" does not return error code != 0 if blah doesn't exist
Explanation:
If asked for a non-existant package, dpkg -s blah will return 0, and not
some other error code.
Strategy:
Make dpkg return some error code and close the bug.
== END ======================================================================
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org finger brinkmd@
Marcus Brinkmann GNU http://www.gnu.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: