Quoting Daniel Hartwig (mandyke@gmail.com): > Hello d-i team > > [alt. subject: system state after successful run of pkgsel is indeterminate] > > Within pkgsel postinst there are a couple uses of aptitude, and one of > tasksel. The invocations are: I wonder whether these calls to aptitude aren't just something forgotten.... > > 1. apply security updates > > 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 > > 2. select and install tasks > > in-target sh -c "tasksel --new-install --debconf-apt-progress='--from > $tasksel_start --to $tasksel_end --logstderr'" || aptfailed > > 3. install packages requested in pkgsel/include > > in-target sh -c "debconf-apt-progress --from 900 --to 950 --logstderr > -- aptitude -q -y install -- $RET" || aptfailed > > Note that all three include "|| aptfailed". > > With tasksel recently switching to apt-get, call 2 will exit with > non-zero status if there are download or (maybe?) installation errors. > (Unless APT::Get::Fix-Missing is being configured somewhere I haven't > noticed.) > > Aptitude 0.6.8 (in testing) does not behave like that. In the event > of those errors it will proceed like apt-get --fix-missing and never > exit with non-zero status. This makes calls 1 and 3 have different > semantics to call 2: they will succeed despite failure to apply > security updates and/or packages requested to be installed. > > Please clarify whether the use of "|| aptfailed" after each call is > intended for catching package download/installation errors (in > addition to other errors, of course). This would mean that a > successful run of pkgsel *should* assert that updates have been > applied, selected tasks installed, and packages in pkgsel/include > installed. At the moment, the state of the system after pkgsel is > indeterminate. > > These semantics could be enforced by replacing use of aptitude with > equivalent calls to apt-get, or updating aptitude to 0.6.9 series (in > experimental) which can report the errors similar to apt-get. IMO > apt-get is preferable because it is simpler and would ensure the most > consistency possible within pkgsel. However, there may be users who > rely on the current implicit support of aptitude-only search patterns > in pkgsel/include. I thik this is what should be done, despite this (minor) inconvenience. We (IIRC) never documented that aptitude search patterns are supported in pkgsel/include. Help in doing this is likely to be appreciated..:-)
Attachment:
signature.asc
Description: Digital signature