Hello, Daniel Hartwig <mandyke@gmail.com> (02/07/2012): > The main bugs concerning this are: 121313, 282408, 302784, 434502, > 576212, 590686, 639789. A quick look at those bugs should indicate > that aptitude's current behaviour has long been considered quite > unusable. thanks for your work on aptitude, it's been in need for love for a long time. > At the end of this command any requested package may or may not have > been installed. In particular, libc6 may have been installed but > obviously some version other than the requested "notaversion". The > only way to determine the state of packages after this is to inspect > each, a rather tedious and error-prone operation. > > With 0.6.9 any requested package or version which is not found will > cause the program to exit with non-zero status *before* making changes > to the system. The entire set of command-line arguments must > constitute a unique, valid package system operation; if there is any > ambiguity or error in the arguments the program will not proceed. It > is not considered sensible to allow a user to restore the old > behaviour of ignoring non-existing packages/versions. Grepping my d-i directory (contained many d-i related package checkouts) I see: packages/pkgsel/debian/postinst: in-target sh -c "debconf-apt-progress --from 50 --to 100 --logstderr -- aptitude -q --without-recommends -y -o DPkg::options=--force-confnew '$upgrade_type'" || aptfailed packages/pkgsel/debian/postinst: in-target sh -c "debconf-apt-progress --from 900 --to 950 --logstderr -- aptitude -q -y install -- $RET" || aptfailed I'm not sure if your changes could trigger regressions in there (e.g. because a buggy command line was more or less working, except for a few faulty packages). > The net result is the program is a much better command-line citizen. > If the exit status is 0 then it is reliable to assume that all > requested actions have been completed [subject to interaction with > --assume-yes and the problem resolver]. This is very much appealing, I must admit, even though I fear bad regressions. Especially on the d-i side… Given we'd like to release beta 1 those days, letting aptitude 0.6.9-1 stay a while in unstable wouldn't help get it tested through d-i beta 1, meaning postponing that to either a beta 2 or rc 1. :( (which would still mean getting changes too late in the release process) > The new version is available on mentors.d.n, we will not upload > however unless granted a freeze exception. Having it uploaded to experimental would be an idea for the time being, so that people can (in an opt-in fashion) test it. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature