Re: Freeze exception request: aptitude 0.6.9-1
On 9 July 2012 07:45, Cyril Brulebois <email@example.com> wrote:
> Grepping my d-i directory (contained many d-i related package checkouts)
Thanks for pointing this out, I had not identified d-i packages when
searching for Depends: aptitude. I had assumed that d-i was using
apt-get and it's more predictable interface.
> 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…
Yes, the convenience of having most packages install even though a few
failed to download may have been very overlooked in the past.
I note that tasksel is invoked between the two runs of aptitude in
pkgsel. With tasksel recently switching to apt-get it too will fail
just as (the proposed) aptitude when there are download or install
errors. If we consider the new tasksel and aptitude as similar in
this case, then the only (?!) new problem is if virtual and/or
non-existent packages are listed in pkgsel/include; previously these
would be ignored, now this is an unavoidable error.
Are there other areas where d-i uses aptitude?
> 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)
If this remains the case (given my previous comments on tasksel) then
I will rather take a look at preparing an in-between version without
the CLI changes (except fix for #434502).
In any event, I have updated the version on mentors to target
experimental and asked sponsors for an upload.
Thanks for looking at my rather verbose request.