[PATCH] pkgsel: remove final use of aptitude (was: pkgsel: please clarify intention of "|| aptfailed")
Hi Please consider reapplying the attached patch to remove the last reliance on aptitude within d-i (pkgsel). There is many months for testing, though no regressions are anticipated as per the previous mails: On 6 August 2012 15:34, Daniel Hartwig wrote: > On 6 August 2012 14:33, Christian PERRIER wrote: >>> 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..:-) >> > > Attached converts the aptitude calls to more-or-less equivalent > apt-get. On an installed system, aptitude is sometimes able to > upgrade a few more packages than apt-get: > > $ aptitude -q --without-recommends -y full-upgrade -s | grep upgraded > 548 packages upgraded, 18 newly installed, 5 to remove and 1 not upgraded. > $ apt-get -q --no-install-recommends -y dist-upgrade -s | grep upgraded > 544 upgraded, 12 newly installed, 2 to remove and 5 not upgraded. > > Given that the upgrade in pkgsel is performed on minimal system this > is unlikely to be much of a difference, but note that I am not > familiar with why pkgsel is using aptitude, or whether this use was > introduced because apt-get was deemed to have issues sometimes. > > Regards --- a/debian/postinst 2012-08-06 14:55:57.225921175 +0800 +++ b/debian/postinst 2012-08-06 14:59:32.697926026 +0800 @@ -76,13 +76,18 @@ tasksel_start=50 else upgrade_type="$RET" + # Convert to apt-get command names. + case "$RET" in + safe-upgrade) upgrade_type=upgrade;; + full-upgrade) upgrade_type=dist-upgrade;; + esac db_progress INFO pkgsel/progress/upgrade sleep 2 # allow the message to be seen log "checking for (security) updates to the base system" # Exclude Recommends to avoid installing new packages as part of # an upgrade. - 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 + in-target sh -c "debconf-apt-progress --from 50 --to 100 --logstderr -- apt-get -q --no-install-recommends -y -o DPkg::options=--force-confnew '$upgrade_type'" || aptfailed tasksel_start=100 fi @@ -145,7 +150,7 @@ # Allow comma-separation so that this can more easily be preseeded # at the kernel command line. RET="$(printf '%s' "$RET" | sed 's/,/ /g')" - in-target sh -c "debconf-apt-progress --from 900 --to 950 --logstderr -- aptitude -q -y install -- $RET" || aptfailed + in-target sh -c "debconf-apt-progress --from 900 --to 950 --logstderr -- apt-get -q -y install -- $RET" || aptfailed fi log "finishing up"
Re: Bug#496068: [synaptic] include debian internet repository by default on new installations
Control: retitle -1 debian-installer: no non-security mirror configured after no-network install Control: reassign -1 debian-installer CSights wrote: > Package: synaptic > Version: 0.62 > Severity: wishlist > > Hi, > I just finished installing "Lenny" from the test CD1. At the time of > installation there was no network interface available. I indicated this to > the installer by choosing. > After booting to Gnome and running Synaptic there is the security > internet > repository available, but no "regular" package repository. (e.g. deb > http://http.us.debian.org/debian main) > I think there is not because during > installation I had no network interface and an internet repository was not > set up. This is correct. A regular mirror may not be configured for a variety of reasons, including that the administrator does not desire this. There should be few assumptions made about forcing particular configuration. > My "wish" is that an internet repository is provided, just like the > security > repository is. It might even be inactive by default. This would allow > newbies to simply select that repository and begin updating their system. Perhaps http.debian.net will soon prove useful enough to be this inactive default mirror. > Not sure if this is a synaptic or debian installer wish, please forward > as > necessary. > > Thanks! Forwarding to debian-installer for that team to ponder. Regards -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8761zo79sh@gmail.com
Downgrading apt-xapian-index from Recommends to Suggests
Hello This bug [1] is from a user who installed on a system with very little amount of memory. The issue is apt-xapian-index (“axi”) updates it's index and makes the system very unresponsive. The use case for axi in aptitude is rather small. It is used to accelerate “aptitude search” on the command line and “Limit Display (l)” interactively when certain terms are used. The terms and their approximate speed-up from having axi installed are: - ?exact-name, 50% - ?term, ?term-prefix, 900% Note that ?term and ?term-prefix are full-text searches specifically designed for use with axi and using either without axi installed produces different search results. I would like to downgrade axi from Recommends to Suggests and will do so for Wheezy unless there are serious objections. Besides large desktop environments (gnome and kde) and sundry, aptitude is the last package which will pull in axi on a typical system. Regards [1] http://bugs.debian.org/685756 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87627is0go@gmail.com
Re: Towards d-i wheezy beta 3
On 10 September 2012 06:07, Cyril Brulebois wrote: > If anybody wants to see something land into this release, it would be > nice to mention it now instead of after the end of the merge window. Is there potential to see pkgsel use apt-get instead of aptitude (following the same change in tasksel)? There is already a patch committed. I'll give this more of a test this week with some induced errors during the installation. Can also add --fix-missing to make apt-get more robust, but I personally don't think that is a good idea. Regards -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAN3veRejAOyCvyZ72aDtESJ3a47RcTjYyoWtsvQ15_m=u9q...@mail.gmail.com
Re: pkgsel: please clarify intention of "|| aptfailed"
On 6 August 2012 14:33, Christian PERRIER wrote: >> 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..:-) > Attached converts the aptitude calls to more-or-less equivalent apt-get. On an installed system, aptitude is sometimes able to upgrade a few more packages than apt-get: $ aptitude -q --without-recommends -y full-upgrade -s | grep upgraded 548 packages upgraded, 18 newly installed, 5 to remove and 1 not upgraded. $ apt-get -q --no-install-recommends -y dist-upgrade -s | grep upgraded 544 upgraded, 12 newly installed, 2 to remove and 5 not upgraded. Given that the upgrade in pkgsel is performed on minimal system this is unlikely to be much of a difference, but note that I am not familiar with why pkgsel is using aptitude, or whether this use was introduced because apt-get was deemed to have issues sometimes. Regards postinst.diff Description: Binary data
pkgsel: please clarify intention of "|| aptfailed"
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: 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. Ok, there is the current release process to be considered. Can the intentions of pkgsel can be stated/determined independently, with the implications of release process considered later? Regards -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/can3vere5v5tu-mst_rsposm4_vv6kkupcf1-sqphqt3s9d6...@mail.gmail.com
Re: Freeze exception request: aptitude 0.6.9-1
On 9 July 2012 07:45, Cyril Brulebois 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. http://mentors.debian.net/package/aptitude Thanks for looking at my rather verbose request. Regards -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAN3veRecs+CQT=w8h3lqg4ugtswfm7mojbrl_4cwd_otqk4...@mail.gmail.com
Re: Freeze exception request: aptitude 0.6.9-1
On 9 July 2012 07:45, Cyril Brulebois wrote: >> 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. I have updated aptitude on mentors to target experimental with version 0.6.9-1~exp1. To ease review, this is the only change at this point. If a sponsor could take a look and please upload. http://mentors.debian.net/package/aptitude http://mentors.debian.net/debian/pool/main/a/aptitude/aptitude_0.6.9-1~exp1.dsc Regards -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/can3verfn92ck9vdsyiopvev4hqykibphajjxmwy9keezxvr...@mail.gmail.com
