The speed critical paths were converted earlier, but the remaining
could benefit a tiny bit from this as well especially as we have the
facility now available and can therefore brush up the code in various
places in the process as well.
Also takes the time to add the hidden Exists method advertised in
the headers, but previously not implemented.
In order to be consistent with other uses of cmp and to improve compatiblity
with other implementations, like busybox one, change long options to short
ones.
Signed-off-by: Walter Lozano <walter.lozano@collabora.com>
`which` has been deprecated in debianutils 5.0+. The recommended
replacement, `command -v`, is mandated by Debian policy these days, in
addition to being required by POSIX and its predecessor specs at least
since 1994.
Not found commands cause no output from `command -v` per POSIX, so
remove the redundant 2>&1's while at it.
As we never display the information in these code paths there isn't a
lot of point in calculating it first saving us some precious CPU cycles.
References: d6f3458bad
An interactive tool like aptitude needs these flags current far more
often than we do as a user can see them in apt only in one very well
defined place – the autoremove display block – so we don't need to run
it up to four times while a normal "apt install" is processed as that is
just busywork.
The effect on runtime is minimal, as a single run doesn't take too long
anyhow, but it cuts down tremendously on debug output at the expense of
requiring some manual handholding.
This is opt-in so that aptitude doesn't need to change nor do we need to
change our own tools like "apt list" where it is working correctly as
intended.
A special flag and co is needed as we want to prevent the ActionGroup
inside pkgDepCache::Init to be inhibited already so we need to insert
ourselves while the DepCache is still in the process of being built.
This is also the reason why the debug output in some tests changed to
all unmarked, but that is fine as the marking could have been already
obsoleted by the actions taken, just inhibited by a proper action group.
If a first step of the solver can figure out that a package is
uninstallable it might reset the candidate so that later steps are
prevented from exploring this dead end. While that helps the resolver it
can confuse the display of the found solution as this will include an
incorrect count of packages not upgraded in this solution.
It was possible before, but happens a fair bit more with the April/May
resolver changes last year so finally doing proper counting is a good
idea.
Sadly this is a bit harder than just getting the number first and than
subtracting the packages we upgraded from it as the user can influence
candidates via the command line and a package which could be upgraded,
but is removed instead shouldn't count as not upgraded as we clearly did
something with it. So we keep a list of packages instead of a number
which also help in the upgrade cmds as those want to show the list.
Closes: #981535
Our http method encodes the URI again which results in the double
encoding we have unwrap in the webserver (we did already, but we skip
the filename handling now which does the first decode).
We accidentally excluded virtual packages by excluding every
group that had a package, but where the package had no versions.
Rewrite the code so the lookup consistently uses VersionList()
instead of FirstVersion and FindPkg("any") - those are all the
same, and this is easier to read.
People are still using apt-key add and friends, despite that not
being guaranteed to work. Let's tell them to stop doing so.
We might still want a list command at a future point, but this
needs deciding, and a blanket ban atm seems like a sensible step
until we figured that out.
The analyze-pattern helper parses a pattern and then renders
the parsed pattern, allowing you to analyze how the parser
interpreted the string.
This can be useful to analyse (yes, analyse-pattern also works)
why a pattern is different from aptitude or why it does not
work as expected.
It can also be used to check if apt has pattern support, although
that will miss out on the version shipped in eoan, but who really
cares about that longer term anyway?
Instead of just using uint32_t, which would allow you to
assign e.g. a map_pointer<Version> to a map_pointer<Package>,
use our own smarter struct that has strict type checking.
We allow creating a map_pointer from a nullptr, and we allow
comparing map_pointer to nullptr, which also deals with comparisons
against 0 which are often used, as 0 will be implictly converted
to nullptr.
This is a first step to a type safe cache, adding typing
information everywhere. Next, we'll replace map_pointer<T>
implementation with a type safe one.
This commit fixes an issue where apt-mark would say it had made a change
before actually making the change. For example, when running as a user
without permission to write to extended_states, the package is not
marked but apt-mark claims it is:
~ % apt-mark manual rxvt-unicode
rxvt-unicode set to manually installed.
E: Could not create [...snip...] (13: Permission denied)
E: Failed to write temporary StateFile /var/lib/apt/extended_states
This commit moves reporting of "[package] set to [manually |
automatically] installed" after saving extended_states and confirming it
was successful.
David Kalnischkies
Julian Andres Klode
Ville Skyttä
Walter Lozano
Julian Andres Klode
Tris Emmy Wilson