Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #173213
| From | Michael Lange <klappnase@freenet.de> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | aptitude cli undocumented behaviour [was: aptitude cli options vs. apt-get ...] |
| Date | 2016-10-05 20:50 +0200 |
| Message-ID | <soZqp-5hM-5@gated-at.bofh.it> (permalink) |
| References | <soQGt-7ks-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
Hi,
On Wed, 5 Oct 2016 11:19:52 +0200
Michael Lange <klappnase@freenet.de> wrote:
(...)
> So my question is: is there a way to include updates to packages put on
> hold to the output of "aptitude full-upgrade" as in apt-get, that I have
> been missing, or is this simply not possible?
I looked again at man aptitude and according to the paragraphs about
"safe-upgrade" and "full-upgrade":
"If no <package>s are listed on the command line, aptitude will attempt
to upgrade every package that can be upgraded. Otherwise, aptitude will
attempt to upgrade only the packages which it is instructed to
upgrade."
I would have expected, that passing the packages put on hold as
arguments, as in
aptitude full-upgrade `aptitude -q=2 -F %p search ~U`
would only try to upgrade these. However when I tried a dry-run on my
almost-up-to-date Jessie box here, with a few holds (hplip and friends) I
got the following surprising result (command lines wrapped by sylpheed):
The list of package holds:
# aptitude -q=2 -F %p search ~ahold
hplip
hplip-data
hplip-gui
libhpmud0
libsane-hpaio
printer-driver-hpcups
Available updates that would be installed by default:
# aptitude -y -v -s full-upgrade | /bin/grep ^Inst | /usr/bin/cut -d\
-f2 | /usr/bin/sort
libdatetime-timezone-perl
tzdata
tzdata-java
# aptitude -y -v -s full-upgrade `aptitude -q=2 -F %p search ~U`
| /bin/grep ^Inst | /usr/bin/cut -d\ -f2 | /usr/bin/sort
hplip
hplip-data
hplip-gui
libdatetime-timezone-perl
libhpmud0
libsane-hpaio
printer-driver-hpcups
tzdata
tzdata-java
tzdata and friends obviously don't have anything to do with hplip, so it
looks like the man page isn't telling the truth.
Can anyone confirm this behaviour, did I misinterpret the manpage, or why
does this happen?
Right now this looks like it is exactly what I have been asking for in
the first post, but the manpage seems to contradict...
Regards
Michael
.-.. .. ...- . .-.. --- -. --. .- -. -.. .--. .-. --- ... .--. . .-.
In the strict scientific sense we all feed on death -- even vegetarians.
-- Spock, "Wolf in the Fold", stardate 3615.4
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
aptitude cli options vs. apt-get (esp. --ignore-hold option) Michael Lange <klappnase@freenet.de> - 2016-10-05 11:30 +0200
Re: aptitude cli options vs. apt-get (esp. --ignore-hold option) Darac Marjal <mailinglist@darac.org.uk> - 2016-10-05 11:50 +0200
Re: aptitude cli options vs. apt-get (esp. --ignore-hold option) Michael Lange <klappnase@freenet.de> - 2016-10-05 12:10 +0200
Re: aptitude cli options vs. apt-get (esp. --ignore-hold option) Jörg-Volker Peetz <jvpeetz@web.de> - 2016-10-05 17:40 +0200
Re: aptitude cli options vs. apt-get (esp. --ignore-hold option) Michael Lange <klappnase@freenet.de> - 2016-10-05 20:30 +0200
aptitude cli undocumented behaviour [was: aptitude cli options vs. apt-get ...] Michael Lange <klappnase@freenet.de> - 2016-10-05 20:50 +0200
Re: aptitude cli undocumented behaviour [was: aptitude cli options vs. apt-get ...] Jörg-Volker Peetz <jvpeetz@web.de> - 2016-10-05 22:40 +0200
[solved]Re: aptitude cli undocumented behaviour [was: aptitude cli options vs. apt-get ...] Michael Lange <klappnase@freenet.de> - 2016-10-06 01:10 +0200
csiph-web