Also even if at the 31st choice we finally get to keep all,
the next day we will still be facing the same problem.
Yes, usually it is just a temporary situation. Upstream was just in the
middle of sending out some packages, etc. But even so,
not for one minute should users be left digging for the
Package: aptitude
Version: 0.8.13-5+b1
Severity: wishlist
In #1064958 we see the usual choice after choice.
Well how about number each choice as it is shown to the user?
With letters, so as not to confuse them with the numbers being shown.
Not just for debugging purposes, but for everyday use.
There it finally was, way down at like the 31st choice.
Accept this solution? [Y/n/q/?] n
XX. The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) apt [2.7.12 (now)]
2) apt-utils [2.7.12 (now)]
3) at-spi2-core
Package: aptitude
Version: 0.8.13-5+b1
Severity: wishlist
Imagine there are 1000 different combinations of
Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:
Remove the following packages:
1) libapt-pkg6.0 [2.7.12 (now, unstable)]
2)
Package: aptitude
Version: 0.8.13-5+b1
Severity: wishlist
Even with Aptitude::CmdLine::Always-Prompt true
there are some cases when prompting still doesn't make sense:
# aptitude full-upgrade
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove
Package: aptitude
Version: 0.8.13-5
Today I out of habit hit RET to the following.
It removed much of my system.
https://www.reddit.com/r/Crostini/comments/alytbc/comment/kcv98ks/
Next time I'll be more careful and not trust it.
I didn't realize how long the list was when I hit RET.
Maybe there
Package: aptitude
Version: 0.8.13-5
Severity: minor
$ aptitude purge -s debian-archive-keyring
The following packages will be REMOVED:
debian-archive-keyring{p}
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get 0 B of archives. After unpacking 276 kB will be
Package: aptitude
Version: 0.8.13-5
autoclean is great, but it would be nice if there could be an optional
way to not have it delete .debs of installed versions.
Yes, most old .debs we don't want anymore,
except if that is the version we actually have installed.
I don't want to throw away a
To be picky, one also notices the man page says ,
which means they are required:
aptitude [...] {build-dep | build-depends | changelog |
download | forbid-version | hold | install | markauto | purge
| reinstall | remove | show | showsrc | source | unhold |
Package: aptitude
Version: 0.8.13-5
Severity: wishlist
$ aptitude show
with no arguments should print a usage message.
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
Package: aptitude
Version: 0.8.13-3
Severity: wishlist
Instead of
# aptitude search xmonad
p libghc-xmonad-contrib-dev- Extensions to xmonad
v libghc-xmonad-contrib-dev-0.16-c9735 -
p libghc-xmonad-contrib-doc- Extensions to xmonad;
Package: aptitude
Version: 0.8.13-3
Severity: minor
# aptitude full-upgrade
Let it download a bit, then hit ^C.
OK do it again:
# aptitude full-upgrade
The following packages will be upgraded:
libdatetime-timezone-perl libllvm12
2 packages upgraded, 0 newly installed, 0 to remove and 0 not
Problem only seen when package is in
$ aptitude search ~i
C a dictionaries-common
state.
I.e., during #995685 .
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
Package: aptitude
Version: 0.8.13-3
# aptitude reinstall dictionaries-common
The following packages will be REINSTALLED:
dictionaries-common
0 packages upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not
upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Do
Also some of them will show up as
v ...
in aptitude search
But some won't show up at all.
Confusing.
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
Also the user is curious where these determinations are drawn from.
It would be nice if aptitude said "Based on /var/lib/dpkg/status, this
package is a ephemeral / virtual / refereed etc. package."
___
Aptitude-devel mailing list
In this particular case, all I found was this package was mentioned in
other installed packages' headers.
I don't know if that makes it a virtual package or not.
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
Package: aptitude
Version: 0.8.13-3
Severity: wishlist
Manpage mentions:
-r, --with-recommends
Treat recommendations as dependencies when installing new packages
(this overrides settings in /etc/apt/apt.conf and
~/.aptitude/config).
This
Package: aptitude
Version: 0.8.13-3
It's just crazy to jumble these like this:
The following packages will be REMOVED:
bubblewrap{pu} (D: libwebkit2gtk-4.0-37) gstreamer1.0-plugins-base{pu} (D:
gstreamer1.0-plugins-good, D: libwebkit2gtk-4.0-37)
gstreamer1.0-plugins-good{pu} (D:
Package: aptitude
Version: 0.8.13-3
Severity: wishlist
$ aptitude show ttf-unifont
Package: ttf-unifont
State: not a real package
$ apt show ttf-unifont
Package: ttf-unifont
State: not a real package (virtual)
That's a little better.
___
Package: aptitude
Severity: wishlist
Version: 0.8.13-3
Let's say there is to be done:
54 packages upgraded, 1 newly installed, 1 to remove and 1 not upgraded etc.
Idea: well in fact, these can be smartly grouped:
First split the list into groups of packages that don't depend on each
other.
Package: aptitude-common
Version: 0.8.13-3
File: /usr/share/man/man8/aptitude-curses.8.gz
https://salsa.debian.org/apt-team/aptitude/-/merge_requests/11
Example 12. Usage of --show-summary --show-summary used with -v to
^
Package: aptitude
Version: 0.8.13-3
I tried but...
# COLUMNS=11 aptitude -w 11 --disable-columns -s install
The following packages will be upgraded:
apt apt-doc apt-utils console-setup console-setup-linux debconf
debconf-i18n debconf-utils e2fsprogs ffmpeg git git-man (git D:
found 902652 0.8.13-3
severity 902652 important
thanks
Proof that aptitude is not ready for
/usr/share/doc/apt/NEWS.Debian.gz
apt (2.1.16) unstable; urgency=medium
Automatically remove unused kernels on apt {dist,full}-upgrade. To revert
to previous behavior, set
Package: aptitude-common
Version: 0.8.13-3
Severity: minor
File: /usr/share/man/man8/aptitude-curses.8.gz
I found that for a package marked as on hold,
doing forbid-version
then unhold
also wipes out forbid-version.
Sure, usually this is what one wants, but this side effect is not
mentioned on
Package: aptitude
Version: 0.8.13-2+b1
Severity: minor
If you think about it, the grammar of
# aptitude install some_package
...
0 packages upgraded, 22 newly installed, 0 to remove and 0 not upgraded.
AA BBC
is weird.
Package: aptitude
Version: 0.8.13-2+b1
Severity: wishlist
This should bomb out right away,
with "E: Unknown pattern type: h",
instead of doing all that work first:
# aptitude search ~h
[ 0%] Reading package lists
[100%] Reading package lists
[ 0%] Building dependency tree
[100%] Building
Package: aptitude
Version: 0.8.13-2
Severity: wishlist
There is
-y, --assume-yes
but no --assume-no.
In particular, let's say we like
$ aptitude -y -s purge beep
The following packages will be REMOVED:
beep{p}
0 packages upgraded, 0 newly installed, 1 to remove and 3 not upgraded.
Need
Glad it will be fixed soon. Thanks.
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
Package: aptitude-common
Version: 0.8.13-1
# aptitude-create-state-bundle /tmp/z
tar: .//root/.aptitude: Cannot stat: No such file or directory
tar: Exiting with failure status due to previous errors
Well the man page says $HOME/.aptitude, which looks different than the
above.
But what's the
It turns out my city computer didn't have that problem. So I can't help
further with any bundles.
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
AB> * APT::AutoRemove::RecommendsImportant (when set to false)
AB> * APT::AutoRemove::SuggestsImportant (when set to false)..
AB> I though was not able to find a combination of these and
AB> Aptitude::Purge-Unused to provoke this behaviour either.
Well
APT::Default-Release "unstable";
> "SJ" == Sven Joachim writes:
SJ> There might be some arguments for "aptitude install " to clear
SJ> the automatic flag (IIRC apt and apt-get do that), but some people
SJ> probably rely on the current aptitude behavior not to do that.
Well like
$ man aptitude
forbid-version
Package: aptitude-doc-en
Version: 0.8.12-3
Severity: minor
File: /usr/share/doc/aptitude/html/en/ch02s02s06.html
That File mentions
You can cancel the “automatic” flag at any time by pressing m...
OK, but do also mention command line equivalents!
Package: aptitude
Version: 0.8.12-3
Odd, today I had to reinstall a package to get aptitude to stop trying
to get rid of it.
# aptitude install fdisk
fdisk is already installed at the requested version (2.35.1-5)
fdisk is already installed at the requested version (2.35.1-5)
The following
Yes, e.g., to convert to a 100% unstable system, one must resort to
outside tools (apt-show-versions),
# set $(apt-show-versions |grep /unknown | sed s!:.*!/unstable!) #or
# set $(apt-show-versions |grep 'newer than version in archive' | sed
s!:.*!/unstable!)
# aptitude install $@
(Also wipes out
Package: aptitude
Version: 0.8.12-1
# aptitude -t sid reinstall package
ignores the -t. Which is too bad.
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel
Package: aptitude
Version: 0.8.11-7
Severity: wishlist
Consider the case
# set libffi6
# apt-cache policy $@
libffi6:
Installed: 3.3~20160224-1
Candidate: 3.3~20160224-1
Version table:
*** 3.3~20160224-1 100
100 /var/lib/dpkg/status
3.2.1-9 500
500
Package: aptitude
Version: 0.8.11-7
User does as instructed, and "i" becomes "iB"!
# aptitude search ~U
i gdal-bin - Geospatial Data Abstraction Library - Utility programs
# aptitude install gdal-bin
The following NEW packages will be installed:
libgdal26{ab} (D: libogdi4.0) (gdal-bin D:
Package: aptitude
Version: 0.8.11-7
Severity: minor
The only way to find old ForbidVer entries is
# grep-status -sPackage,ForbidVer -F ForbidVer --ge 0
/var/lib/aptitude/pkgstates
Package: chromium-common
ForbidVer: 74.0.3729.108-1
As one couldn't just look for any "F" in this list
# aptitude
Package: aptitude
Version: 0.8.11-7
Severity: wishlist
If a package is installed, one can forbid-version, and / or hold it.
But if a package is not installed yet, one cannot!
One cannot say "I want to hold package X's status as 'purge'" to prevent
future accidental installation.
"Version ABC
Package: aptitude
Version: 0.8.11-7
Here we see the user answers only "n"s and "q"s,
but still the apt-mark is cleared!
# apt-mark hold gcc-9-base
gcc-9-base set on hold.
# aptitude full-upgrade
...
The following actions will resolve these dependencies:
Install the following packages:
1)
Package: aptitude
Version: 0.8.11-7
Severity: minor
If a user does
$ aptitude show package1 package2...
and one of them is a virtual package, it "glues itself onto the header of
the following package", because it is missing its blank line at bottom.
# aptitude show twitter-bootstrap
Package: aptitude
Version: 0.8.11-7
Severity: wishlist
File: /usr/bin/aptitude-curses
Black upon blue text very hard to read:
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
Package: aptitude
Version: 0.8.11-7
Severity: minor
One sees a (harmless) // in:
E: Cannot remove aptitude within aptitude
E: Problem parsing '/var/lib/aptitude//pkgstates', is it corrupt or malformed?
You can try to recover from '/var/lib/aptitude//pkgstates.old'.
Reproduce by doing
dpkg
Package: aptitude
Version: 0.8.10-9
Aptitude's "~o" search string is not good enough.
It doesn't catch cases like in Bug #902503.
For such cases one needs
# aptitude -F '%t %p' search ~i!~o|perl -nwle 'print if s/^now //;'
firefox
libffi6
That's the only way one is going to find them.
#
Package: aptitude-doc-en
Version: 0.8.10-9
File: /usr/share/doc/aptitude/html/en/ch02s05s01.html
In Customizing the package list, We read
%t Archive 10 Yes The archive in which the package is found.
But it turns out that is only shows you the first,
# aptitude show emacs
Archive:
AB> "update the package lists" is already very precise.
Well it may mean the lists of available packages,
or maybe the lists of states of packages, the user worries.
___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
Package: aptitude
Version: 0.8.10-9
Severity: wishlist
If this happens:
[ ERR] Reading package lists
E: Problem renaming the file /var/cache/apt/pkgcache.bin.qwWJaB to
/var/cache/apt/pkgcache.bin - rename (2: No such file or directory)
W: You may want to update the package lists to correct
Package: aptitude
Version: 0.8.10-9
# aptitude search exim4-config
Cr exim4-config
# aptitude reinstall exim4-config
The following packages will be REINSTALLED:
exim4-config
...
E: Internal Error, No file name for exim4-config:amd64
___
Package: aptitude
Version: 0.8.10-9
Here it says it is marking the (uninstalled) package as hold, but we
observe it doesn't actually.
# set openjdk-11-jre-headless
# aptitude search $@
p openjdk-11-jre-headless-
OpenJDK Java runtime, using Hotspot
51 matches
Mail list logo
