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

Re: Freeze exception request: aptitude 0.6.9-1


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

> 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.


Attachment: signature.asc
Description: Digital signature

Reply to: