[Piuparts-commits] rev 223 - in trunk: . debian piupartslib

[Holger Levsen]

Author: holger
Date: 2009-03-13 23:41:16 +0000 (Fri, 13 Mar 2009)
New Revision: 223

Modified:
   trunk/TODO
   trunk/debian/changelog
   trunk/piupartslib/packagesdb.py
Log:
Experiment to try to make packages testable, which have circular 
dependencies. I think think this should work, because I believe package 
with circular dependencies can simply be tested together - the remaining
issue is to find out, which package really failed...

Modified: trunk/TODO
===================================================================
--- trunk/TODO	2009-03-12 01:05:14 UTC (rev 222)
+++ trunk/TODO	2009-03-13 23:41:16 UTC (rev 223)
@@ -1,56 +1,51 @@
 Things to do for piuparts
 =========================
 
-* piuparts can't currently test postfix, since installing postfix removes
-exim and removing postfix would require re-installing exim, and that
-doesn't happen; there's other packages like that, too
+- upgrade-reports should have a list of available arch and list packages 
+  only available on untested archs in a new state categorory.
 
-* piuparts can't currently test upgrades of requiered packages. (Because they
-cannot be removed, it assumes these are untestable, which is only true for
-removal tests...
+- piuparts can't currently test upgrades of required packages. (Because they
+  cannot be removed, it assumes these are untestable, which is only true for
+  removal tests...
 
-----------------
-
 - find_default_debian_mirrors: if parts[2] contains a / (think
   stable/updates for security.d.o), you can't ignore this, it will break
   later...
 
-- wishlist: make it possible to call aptitude (or similar) instead
-  of apt-get and allow to override the commandline arguments of
-  the used program (to be able to test with and without recommended 
-  packages or authentication).
+- piuparts can't currently test postfix, since installing postfix removes
+  exim and removing postfix would require re-installing exim, and that
+  doesn't happen; there's other packages like that, too
 
 - mounting /proc and perhaps others (usbfs, sysfs, /dev/pts, etc.) in
   the chroot might be a good idea because some packages might need this.
   Interestingly enough this currently seems to prevent start-stop-daemon
   from starting any daemons ;)
 
-Frank Lichtenheld <djpig at debian.org>
-
-
 Low priority stuff (a.k.a. "nobody's said they must have it now")
 -----------------------------------------------------------------
 
+* make it possible to call aptitude (or similar) instead of apt-get and 
+  allow to override the commandline arguments of the used program (to be 
+  able to test with and without recommended packages or authentication).
+
 * Kill children after a timeout to make sure the test doesn't run forever.
 
 * Check for and kill extraneous processes afterwards. Perhaps by checking
-whether their working directory is in the chroot.
+  whether their working directory is in the chroot.
 
-* toresbe:
+* include a test to see which packages which modify their own conffiles 
+  so the user is presented with a dpkg conffile changed dialogue during
+  the upgrade.  It would also be very interesting to see how many packages
+  leave behind orphaned conffiles after purging a newer version which does
+  not contain the files anymore.
 
-  Indeed.  And if you can, Lars, please include a test to see which
- packages which modify their own conffiles so the user is presented with
- a dpkg conffile changed dialogue during the upgrade.  It would also be
- very interesting to see how many packages leave behind orphaned
- conffiles after purging a newer version which does not contain the
- files anymore.
-
 * deal with packages that need to replace higher priority packages
-(which then need to be put back when the package is removed)
+  (which then need to be put back when the package is removed)
 
 * Bill Allombert: Does piupart test whether packages trigger useless
-conffiles handling ? (i.e. dpkg pretend you have modified a conffile
-when it has not) this is one kind of bugs I would really get rid of.
+  conffiles handling ? (i.e. dpkg pretend you have modified a conffile
+  when it has not) this is one kind of bugs I would really get rid of.
+  h01ger: #466118 sounds like it does.
 
 * piuparts-slave: keep track of reservations permanently
 * piuparts-master: keep track of whom a reservation is made

Modified: trunk/debian/changelog
===================================================================
--- trunk/debian/changelog	2009-03-12 01:05:14 UTC (rev 222)
+++ trunk/debian/changelog	2009-03-13 23:41:16 UTC (rev 223)
@@ -10,6 +10,10 @@
     package is of priority "required", and not whether it's "Essential".
   * Rename status "essential-required-important" to "essential-required" 
     as important packages can be tested like all the others.
+  * Experiment to try to make packages testable, which have circular 
+    dependencies. I think think this should work, because I believe package 
+    with circular dependencies can simply be tested together - the remaining
+    issue is to find out, which package really failed...
 
  -- Holger Levsen <holger at debian.org>  Tue, 10 Mar 2009 15:23:59 +0100
 

Modified: trunk/piupartslib/packagesdb.py
===================================================================
--- trunk/piupartslib/packagesdb.py	2009-03-12 01:05:14 UTC (rev 222)
+++ trunk/piupartslib/packagesdb.py	2009-03-13 23:41:16 UTC (rev 223)
@@ -208,7 +208,7 @@
         "dependency-failed-testing": "dependency-failed-testing",
         "dependency-cannot-be-tested": "dependency-cannot-be-tested",
         "dependency-does-not-exist": "dependency-does-not-exist",
-        "circular-dependency": "circular-dependency",
+        "circular-dependency": "waiting-to-be-tested",
         "dependency-fix-not-yet-tested": "dependency-fix-not-yet-tested",
     }