| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
A specific CLI version can now be requested using the --cli-version
flag, and old versions can be deprecated on a reasonable cadence.
Therefore, a warning is no longer necessary.
Gbp-Dch: full
|
| |
|
|
| |
Extract almost all dependency logic into a subclass
|
| |
|
|
|
|
|
| |
This removes the need for the forward references, thus fixing part
of the libc++ issues pointed out in [merge-511].
[merge-511] https://salsa.debian.org/apt-team/apt/-/merge_requests/511/diffs
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
These are implemented somewhat differently from aptitudes
why and why-not commands: They produce the actual solver
trace for why a particular decision has been taken.
For the why-not case, we need to explicitly discover our
specified package, as if nothing else depends on it in
our graph, it would otherwise always be undiscovered and
conflicts not detected (see e.g. level-3 in the test).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This handles rewriting .list entries to .sources ones; the
only options handled are
- signed-by => Signed-By
- trusted => Trusted
The options to specify architectures, check-valid-until, etc.
are not supported as they are not exposed in the code. We
probably should refactor the parser at some point so we can
actually read the parsed entry rather than the abstract objects
we create from it.
This can be improved further:
- Keyrings from /etc/apt/trusted.gpg.d should be moved to
/etc/apt/keyrings.
- automatic detection by trying to verify using each keyring
in trusted.gpg.d until we find the right one and then using
that for Signed-By rather than leave some sources empty.
|
| |
|
|
|
|
|
| |
We assume all files in the 'listsdir' are candidates. Keep only files
ending with Release, Release.gpg, and InRelease.
Closes: #959093
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Allow to satisfy dependency strings supplied on
the command line, optionally prefixed with
"Conflicts:" to satisfy them like Conflicts.
Build profiles and architecture restriction lists,
as used in build dependencies, are supported as
well.
Compared to build-dep, build-essential is not
installed automatically, and installing of recommended
packages follows the global default, which defaults
to yes.
Closes: #275379
See merge request apt-team/apt!63
|
| |
|
|
| |
aptitude has a similar "reinstall" command for precedent.
|
| |\ |
|
| | |
| |
| |
| | |
Muscle memory is acquired from querying package
info with tools like snap, dnf etc.
|
| |/
|
|
|
|
|
| |
This adds a new "autopurge" command that will is a shortcut for
"autoremove --purge"
Thanks: Michael Vogt for the initial work
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it easier to see which headers includes what.
The changes were done by running
git grep -l '#\s*include' \
| grep -E '.(cc|h)$' \
| xargs sed -i -E 's/(^\s*)#(\s*)include/\1#\2 include/'
To modify all include lines by adding a space, and then running
./git-clang-format.sh.
|
| |
|
|
|
| |
Broken in e7e10e47476606e3b2274cf66b1e8ea74b236757 by looking always
into "apt" while we ship some tools in "apt-utils"…
|
| |
|
|
| |
Git-Dch: Ignore
|
| |
|
|
|
|
|
|
| |
Passing function pointers around while working on this was very icky,
but if weak symbols are too much to ask for…
Reverts "do not use "-Wl,-Bsymbolic-functions" during the build to avoid
breakage" aka a5fc9be36211a290a7abc3ca2a8bf98943bc1f57.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The general idea is: A small paragraph on the tool itself as a
description, a list of the most used (!= all) commands available in the
tool, a remark where to find more information on the tool and its
commands (aka: in the manpage) and finally a common block referring to
even more manpages. In exchange options are completely omitted from the
output as well as deprecated or obscure commands. (Better) Information
about them is available in the manpages anyway and the few options which
were listed before were also the least interesting ones (-o -c -q and co
are hardly of interest for someone totally new looking to find info by
asking for help and anyone with a bit of experience doesn't need this
short list. Those would need a list of options applying to the command
they call, but they are too numerous and command specific to list them
sanely in this context.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
apt is supposed to be a user-friendly interface, so while these commands
are usually poweruser material and therefore do not need to be shown in
general introduction manpages/help messages its of no use to not allow
users to use them.
This includes clean, autoclean, build-dep, source, download, changelog,
depends, rdepends and showsrc – it doesn't include more non-interactive
commands like dump or xvcg as those are usually used by scripts if at
all.
Closes: 778234, 780700, 781237
|
| |
|
|
| |
Git-Dch: Ignore
|
| |
|
|
|
|
|
|
| |
Its not as simple as I initially thought to abstract this enough to make
it globally usable, so lets not pollute global namespace with this for
now.
Git-Dch: Ignore
|
| |
|
|
|
|
|
| |
This ensures that location strings loaded from a location specified via
configuration (Dir::Locale) effect the help messages for commands.
Git-Dch: Ignore
|
| |
|
|
|
|
|
|
|
| |
-q is for logging and -qqq (old -qq) basically kills every output expect
errors, so there should be a way of declaring a middleground in which
the output of e.g. 'update' isn't as verbose, but still shows some
things. The test framework was actually making use of by accident as it
ignored the quiet level in output setup for apt before.
Eventually we should figure out some better quiet levels for all tools…
|
| |
|
|
|
|
|
|
| |
All mains pretty much do the same thing, so lets try a little harder to
move the common parts into -private to have the real differences more
visible.
Git-Dch: Ignore
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
That is one huge commit with busy work only: Help messages used to be
one big translateable string, which is a pain for translators and hard
to reuse for us. This change there 'explodes' this single string into
new string for each documented string trying hard to split up the
translated messages as well. This actually restores many translations as
previously adding a single command made all of the bug message fuzzy.
The splitup also highlighted that its easy to forget a line, duplicate
one and similar stuff.
Git-Dch: Ignore
|
| |
|
|
| |
Git-Dch: Ignore
|
| |
|
|
|
|
|
|
|
|
| |
The show commands have different styles in both binaries as the audience
is potentially very different, but that doesn't mean we need to separate
the implementation especially as they are slightly similar. This also
allows us to switch between the different show versions at runtime via
an option.
Git-Dch: Ignore
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As part of the “reproducible builds” effort [1], we have noticed that
apt could not be built reproducibly.
One issue is that it uses the __DATE__ and __TIME__ macros of the C
preprocessor to display the time of build in the online help. We believe
this information not to be really useful to users as they can always
look at the package data and metadata to figure it out.
The attached patch simply removes this information. All
non-documentation packages can then be built reproducibly with our
current experimental framework.
[David: changed the string slightly to be untranslateable as well]
Closes: 774342
|
| |
|
|
|
|
|
| |
By convention, if I run a tool with --help or --version I expect it to
exit successfully with the usage, while if I do call it wrong (like
without any parameters) I expect the usage message shown with a non-zero
exit.
|
| |\ |
|
| | |
| |
| |
| | |
Closes: 748389
|
| |/ |
|
| |
|
|
| |
Closes: 743413
|
| | |
|
| |
|
|
|
|
|
|
| |
Beside being a bit cleaner it hopefully also resolves oddball problems
I have with high levels of parallel jobs.
Git-Dch: Ignore
Reported-By: iwyu (include-what-you-use)
|
| |
|
|
|
| |
Reported-By: gcc -Wunused-parameter
Git-Dch: Ignore
|
| |
|
|
|
| |
Git-Dch: Ignore
Reported-By: gcc -Wmissing-declarations
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
| |
There is a new "apt full-upgrade" that performs a apt-get dist-upgrade.
"apt dist-upgrade" is still supported as a alias. The "apt upgrade" code
is changed so that it mirrors the behavior of
"apt-get upgrade --with-new-pkgs" and also honors
"apt uprade --no-new-pkgs".
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
