Hi Daniel, thank you for the explanations. And thank you for your work on aptitude. I appreciate it. I use aptitude regularly from the command-line. -- Best regards, Jörg-Volker.
Daniel Hartwig wrote, on 11/20/12 02:34: > Control: retitle -1 aptitude: man page mentions old “-t” exceptions > Control: tags -1 + confirmed > > On 19 November 2012 17:22, Jörg-Volker Peetz <jvpe...@web.de> wrote: >> the command >> >> aptitude -t unstable show <package> >> >> actually shows information of the version of <package> in the default (here: >> testing) release, while the command >> >> aptitude show <package>/unstable >> >> works as described in the documentation of aptitude and shows the >> description of <package> in the unstable release. > > The section describing “-t” in aptitude(8) describes an exception to > the normal handling of this argument [1] for three commands. That > exception is inconsistent with other aptitude commands, and apt, > including the equivalent commands in apt-get and apt-cache. This made > use of “-t” problematic and lead to unexpected results across > combinations of commands. For example: > > $ cat /etc/apt/preferences > Package: xsltproc > Pin: release a=unstable > Pin-Priority: 991 > > $ aptitude changelog -t experimental xsltproc > [details from experimental version, due to “-t” exception for > “aptitude changelog”] > $ apt-get changelog -t experimental xsltproc > [details from unstable, apt-get has no “-t” exceptions] > $ su > # aptitude install -t experimental xsltproc > [installs unstable version, due to apt_preferences(5) and lack of “-t” > exception for “install”] > > The “-t” exceptions have been removed to avoid this. That section of > the man page will be updated. > >> >> In previous versions of aptitude both commands resulted in the same >> output. > > True. The intention of current versions is that “-t unstable > <package>” is not necessarily equivalent to “<package>/unstable” in > any commands, and only has effect via the usual apt_preferences(5) > mechanism. All of > aptitude and apt-get are now consistent in that regard, and the > problematic section of the man page will be updated. > > Thanks for the report, I had missed that man page section when making > this change. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org