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

Bug Stamp Out List


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

"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

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 :)


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.
 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.
 Make dselect return to the main menu if Select is choosen while database is

Report: 1642
Status: Open, can be closed.
Changelog: See dpkg 1.0.6
Analyse: dselect recursive dependency resolution doesn't do the right thing.
 Raul says that dselect's recursive dependency resolution doesn't work if
 recommended packages aren't available.
 As dselect spits out messages about his today, this bug report can be

Report: 1818
Status: Open, normal.
Analyse: dpkg should base configure ordering on Recommends
 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).
 Needs code to fix it.

Report: 2531
Status: Open, can be closed?
Analyse: install-info needs better locking strategy.
 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
 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.
 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.
 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.
 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.
 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.
--- install-info.old	Mon Feb  1 01:21:22 1999
+++ install-info	Fri Mar  5 20:58:21 1999
@@ -27,6 +27,7 @@
 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.
 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.
 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.
 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.
 Close the report.

Report: 3233
Status: Open, can hopefully be closed.
Analyse: bugs in dselect of 1.1.
 Heiko describes two bugs here, but didn't gave additional
 information needed.
 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.
 When installed version is later then available version, dselect enters the
 conflict resolution screen even with no conflict.
 As this bug was fixed in 1.2.11, the report can be closed.

Report: 4074
Status: Open, ???
Analyse: ???
 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).


Report: 4195
Status: Open, can probably be fixed and closed.
Analyse: dpkg-source contains a hack to work with broken tar.
 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.
 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: 4319
Status: Open, unclear.
Analyse: dpkg does overwrite changed conffiles during upgrade
 The claim was made that dpkg overwrote silently changed conffiles during
 package upgrade, but it is not proven. It is hard to reproduce what
 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").
 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.
 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
Analyse: Argument to $rootcommand should be quoted.
 The argument to the $rootcommand in dpkg-buildpackage should be quoted, so
 "su -c" does work with command "debian/rules build".
 This bug was fixed in dpkg 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
 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.
 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.
 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.
 If a package is upgraded, and the old postrm _fails_, and there is no new
 postrm, dpkg will give up.
 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
 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.
 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.
 dpkg doesn't set the permissions of directoryy according to theinformation
 in the package. This is deliberately, but should be documented.
 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
 If asked for a non-existant package, dpkg -s blah will return 0, and not
 some other error code.
 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: