| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Calculate an estimate of 110% of the biggest initrd + system.map
as the additional space a kernel needs in /boot.
If /boot is a different file system than /usr, print the size of
the kernels + the additional space they will need separately;
otherwise include it in our /usr figure.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The key talking points here are:
1. Instead of long sentences, we use short concise messages,
e.g. "The following NEW packages will be installed" becomes
"Installing".
2. Dependencies are only listed once. We removed the
"The following additional packages will be installed" section
in favor of splitting up the "Installing" section into
"Installing" and "Installing dependencies" (like dnf)
3. The order of the output is different:
1. Packages to be installed manually
2. Packages to be installed automatically
4. Weak dependencies of new packages not installed
3. Packages to be upgraded
4. Packages to be downgraded
5. Packages that have been kept back / are on hold
6. Removals
7. Essential removals
i.e. we logically show you the action that is being
done, followed by lists related to the action.
4. As requested by popey, we have colorful UI, with green for
packages being installed and red for packages being removed.
Caveats:
- The list of recommends and suggests has not been updated yet,
it should move to after the packages being installed (as they
are what triggers them)
This also introduces output format versioning, configured by the
APT::Output-Format option. The default value is 0, except for the
apt(8) binary where it is 30 - which enables the new style.
|
| |
|
|
|
|
|
|
|
|
|
| |
It's interesting to the user to see the progress when it happens,
but arguably once it's done it is just visual clutter, so let's
not write newlines, and when we are done, instead of appending
"Done", let's just empty the line.
This requires some effort to keep apt-cdrom happy which just writes
lines to stdout itself. Bad apt-cdrom. Maybe there is a better fix
for it, but this gets us going.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change makes it a bit easier to quickly grasp the changes
about to be performed by apt.
It displays package lists in a columnar format by default,
similar to what `ls` produces for files.
A new long option `--no-list-columns` and an associated
`APT::Get::List-Columns` config setting control the behavior.
Usage example, with 60 column wide terminal:
```
$ sudo apt upgrade |
Reading package lists... Done |
Building dependency tree... Done |
Reading state information... Done |
Calculating upgrade... Done |
The following packages were automatically installed and are |
no longer required: |
libappindicator1 libindicator7 |
libdbusmenu-gtk4 linux-image-5.14.0-4-amd64 |
Use 'sudo apt autoremove' to remove them. |
The following packages have been kept back: |
criu linux-headers-amd64 nvidia-settings |
libxnvctrl0 nvidia-modprobe xwayland |
0 upgraded, 0 newly installed, 0 to remove and 6 not upgrade|
d. |
```
The effect becomes more pronounced with more packages (e.g. when
doing a dist-upgrade).
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The assertion can be overriden using apt::key::assert-pubkey-algo,
the default is the most opinionated one.
This will inform the user during apt-cdrom add as we do not
pass --quiet to user, so adjust test case.
Add a simple test case for it to test-method-gpgv.
LP: #2055193
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit introduces the following configuration for keeping a
configurable amount of kernels: APT::NeverAutoRemove::KernelCount
The logic dictates that the running kernel and the latest kernel are not
autoremoved. In case the running kernel is the latest kernel, the
previous kernel is kept. Any count lower than two is therefore
disregarded. This is in line with the previous behavior.
The default is therefore similar to:
APT::NeverAutoRemove::KernelCount 2;
This will be ignored and we will still keep two:
APT::NeverAutoRemove::KernelCount 1;
This will keep 3 kernels (including the runnig, and most recent)
APT::NeverAutoRemove::KernelCount 3;
Signed-off-by: Wesley Schwengle <wesleys@opperschaap.net>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Usually this method will return the package in the most preferred
architecture (e.g. native) as that is usually what the user talks about
and also information wise for our internal usage the most dense.
Early on in parsing Packages files through it can happen that we
encounter stanzas about packages in architectures we are not even
configured to know about – we have to collect them anyhow as we might be
requested to show info about them or they could be in the status file
and we can't ignore stanzas in the status file… trouble is that this
method used to not return anything if only such an architecture was
present if we later discover other architectures which causes Provides
and Conflicts which are added lazily on discovery of an architecture
to not be added correctly.
The result is like in the testcase that apt could be instructed to
install a package without respecting its negative dependencies, which is
bad even if its discovered by dpkg and refused. It does only happen with
unknown architectures through which mostly happens if you are unlucky
(amd64 users tend to be very lucky as that sorts early) and use
flat-style repositories containing multiple architectures.
Reported-By: Tianyu Chen (billchenchina) on IRC
|
| |
|
|
|
|
|
| |
We want to gently steer users towards having Signed-By for each
source such that we can retire a shared keyring across sources
which improves resilience against configuration issues and
incompetent malicious actors.
|
| |
|
|
|
| |
This will attempt to fallback to a per-server setting if we could
not determine a value from the release file.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provide snapshot support for offical Debian and Ubuntu archives.
There are two ways to enable snapshots for sources:
1. Add Snapshot: yes to your sources file ([snapshot=yes]). This
will allow you to specify a snapshot to use when updating or
installing using the --snapshot,-S option.
2. Add Snapshot: ID to your sources files to request a specific
snapshot for this source.
Snapshots are discovered using Label and Origin fields in the Release
file of the main source, hence you need to have updated the source at
least once before you can use snapshots.
The Release file may also declare a snapshots server to use, similar
to Changelogs, it can contain a Snapshots field with the values:
1. `Snapshots: https://example.com/@SNAPSHOTID@` where `@SNAPSHOTID@`
is a placeholder that is replaced with the requested snapshot id
2. `Snapshots: no` to disable snapshot support for this source.
Requesting snapshots for this source will result in a failure
to load the source.
The implementation adds a SHADOWED option to deb source entries,
and marks the main entry as SHADOWED when a snapshot has been
requested, which will cause it to be updated, but not included
in the generated cache.
The concern here was that we need to keep generating the shadowed
entries because the cleanup in `apt update` deletes any files not
queued for download, so we gotta keep downloading the main source.
This design is not entirely optimal, but avoids the pitfalls of
having to reimplement list cleanup.
Gaps:
- Ubuntu Pro repositories and PPAs are not yet supported.
|
| |
|
|
|
| |
This runs update before opening the cache and sources.list for
installing/upgrading.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In an ideal world everyone would read release notes, but if the last
sources.list change is any indication a lot of people wont. This is
even more a problem in so far as apt isn't producing errors for
invalid repositories, but instead carries on as normal even through it
will not be able to install upgrades for the moved packages.
This commit implements two scenarios and prints a notice in those cases
pointing to the release notes:
a) User has 'non-free' but not 'non-free-firmware'
b) User has a firmware package which isn't available from anywhere
Both only happen if we are talking about a repository which identifies
itself as one of Debian and is for a release codenamed bookworm (or
sid). Note that as (usually) apt/oldstable is used to upgrade to the
new stable release these suggestions only show for users after they
have upgraded to bookworm on apt command line usage after that.
|
| |
|
|
|
|
| |
This changes a lot of lines technically, but its easy enough to unfuzzy
the translations as most of the mentions are examples to be copied
literally in translations (sadly po4a isn't clever enough for this).
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a lot closer to the original implementation in update-manager,
but still has a couple of differences that might cause bugs:
- When checking whether a version is a security update, we only
check versions in between and not any later version. This happens
mostly because we do not know the suite, so we just check if there
is any version between the installed version and our target that
is a security update
- We only keep already installed packages, as we run before the
resolver. update-manager first runs the resolver, and then marks
for keep all packages that were upgraded or newly installed that
are phasing (afaict).
This approach has a significant caveat that if you have version 1
installed from a release pocket, version 2 is in security, and version
3 is phasing in updates, that it installs version 3 rather than 2
from security as the policy based implementation does.
It also means that apt install does not respect phasing and would
always install version 3 in such a scenario.
LP: #1979244
|
| |
|
|
|
|
|
|
| |
Suggesting the removal of Essential and Protected packages as a
solution leads to situations where YouTubers end up removing their
desktop.
Let's not remove such packages ourselves.
|
| |\
| |
| |
| |
| | |
Add AllowRange option to disable HTTP Range usage
See merge request apt-team/apt!188
|
| | |
| |
| |
| |
| |
| |
| |
| | |
apt makes heavy usage of HTTP1.1 features including Range and If-Range.
Sadly it is not obvious if the involved server(s) (and proxies) actually
support them all. The Acquire::http::AllowRange option defaults to true
as before, but now a user can disable Range usage if it is known that
the involved server is not dealing with such requests correctly.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
APT is not the place this information should be stored at, but it is a
good place to experiment and see what will be (not) needed in the future
for a proper implementation higher up the stack.
This is why "BarbarianArchitectures" is chosen instead of a more neutral
and/or sensible "VeryForeign" and isn't readily exported in the API to
other clients for this PoC as a to be drawn up standard will likely
require potentially incompatible changes. Having a then outdated and
slightly different implementation block a "good" name would be bad.
The functionality itself mostly exists (ignoring bugs) since the
introduction of MultiArch as we always had the risk of encountering
packages of architectures not known to dpkg (forced onto the system,
potentially before MultiArch) we had to deal with somehow and other
edge cases.
All this commit really does is allowing what could previously only be
achieved with editing sources.list and some conf options via a single
config option: -o APT::BarbarianArchitectures=foo,bar
|
| |
|
|
|
|
| |
This is very basic support on the testing side, we just test
the debug output but not how long it actually took. Would be
nice to check time really.
|
| |
|
|
|
|
|
| |
Add a new Item field called FetchAfter, which determines the earliest
time the item should be fetched at. Adjust insertion into queue to
take it into account alongside priority, and only fill pipelines
with items that are ready.
|
| |
|
|
| |
It defaults to false, like the other options there do.
|
| |
|
|
|
|
|
|
|
| |
Repositories without Size information for packages are not
proper and need fixing. This ensures people see an error in
CI, and get notifications and hence the ability to fix it.
It can be turned off by setting Acquire::AllowUnsizedPackages
to true.
|
| |
|
|
|
|
|
|
|
|
|
| |
People have been asking for a feature to error out on transient network
errors for a while, this gives them one while keeping the door open for
other modes we need, such as --error-on=no-success which we need to
determine when to retry the daily update job.
Closes: #594813
(and a whole bunch of duplicates...)
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds support for Phased-Update-Percentage by pinning
upgrades that are not to be installed down to 1.
The output of policy has been changed to add the level of
phasing, and documentation has been improved to document
how phased updates work.
The patch detects if it is running in a chroot, and if so, always
includes phased updates, restoring classic apt behavior to avoid
behavioral changes on buildd chroots.
Various options are added to control this all:
* APT::Get::{Always,Never}-Include-Phased-Updates and their legacy
update-manager equivalents to always or never include phased updates
* APT::Machine-ID can be set to a UUID string to have all machines in a
fleet phase the same
* Dir::Etc::Machine-ID is weird in that it's default is sort of like
../machine-id, but not really, as ../machine-id would look up
$PWD/../machine-id and not relative to Dir::Etc; but it allows you to
override the path to machine-id (as opposed to the value)
* Dir::Bin::ischroot is the path to the ischroot(1) binary which is used
to detect whether we are running in a chroot.
|
| |
|
|
|
| |
Kernels clutter /boot and /boot is small size, so we need to take
extra care to remove kernels when possible.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our kernel autoremoval helper script protects the currently booted
kernel, but it only runs whenever we install or remove a kernel,
causing it to protect the kernel that was booted at that point in time,
which is not necessarily the same kernel as the one that is running
right now.
Reimplement the logic in C++ such that we can calculate it at run-time:
Provide a function to produce a regular expression that matches all
kernels that need protecting, and by changing the default root set
function in the DepCache to make use of that expression.
Note that the code groups the kernels by versions as before, and then
marks all kernel packages with the same version.
This optimized version inserts a virtual package $kernel into the cache
when building it to avoid having to iterate over all packages in the
cache to find the installed ones, significantly improving performance at
a minor cost when building the cache.
LP: #1615381
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We do not deal a lot with URIs which need encoding, but then we do it is
a pain that we store it decoded in the acquire system as it means we
have to decode and reencode URIs eventually which is potentially giving
us slightly different URIs.
We see that in our own testing framework while setting up redirects as
the config options are effectively double-encoded and decoded to pass
them around successfully as otherwise %2f and / in an URI are treated
the same.
This commit adds the infrastructure for methods to opt into getting URIs
send in encoded form (and returning them to us in encoded form, too) so
that we eventually do not have to touch the URIs which is how it should
be. This means though that we have to deal with methods who do not
support this yet (aka: all at the moment) for which we decode and encode
while communicating with them.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Merging patches is a bit of non-trivial code we have for client-side
work, but as we support also server-side merging we can export this
functionality so that server software can reuse it.
Note that this just cleans up and makes rred behave a bit more like all
our other binaries by supporting setting configuration at runtime and
supporting --help and --version. If you can make due without this, the
now advertised functionality is provided already in earlier versions.
|
| |\
| |
| |
| |
| | |
Support marking all newly installed packages as automatically installed
See merge request apt-team/apt!110
|
| | |
| |
| |
| |
| |
| |
| | |
Add option '--mark-auto' to 'apt install' that marks all newly installed
packages as automatically installed.
Signed-off-by: Nicolas Schier <nicolas@fjasle.eu>
|
| |/
|
|
| |
This will be mapped to Important for the time being.
|
| |
|
|
|
|
|
|
| |
Especially if a lot packages have to be removed due to not to explicitly
expressed conflicts the problem resolver can take a few turns to remove
them all. Allowing it to try a little longer if needed seems beneficial
as the worst which can happen is that we now take two times as long to
present an error message to the user.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Include that apt is being run from a service in the user
agent, so traffic can be analysed for interactive vs
non-interactive use, and prioritised accordingly.
It looks like this now:
User-Agent: Debian APT-HTTP/1.3 (2.0.1) non-interactive
A previous version included the full service names, but this
raised some privacy concerns.
LP: #1825000
|
| |
|
|
|
|
|
|
|
|
|
| |
This caused unbound error list growth, because each time
we dumped an error, the calls to _config->FindB() inside
operator << would add 3 new errors of the form:
W: Using unknown config option »apt::color« of type BOOL
Hence we are dumping an infinite list of errors, and eventually
that list will exceed available memory.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Showing a percentage for a timeout is pretty non-standard. Rework the
progress class so it can show an absolute progress (currently hardcoded
to use seconds as a unit). If there is a timeout (aka if it's not the
maximum long long unsigned -1llu), then show the timeout, otherwise
just count up seconds, e.g.
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 33842 (apt)... 1/120s
or
Waiting for cache lock: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 33842 (apt)... 1s
Also improve the error message to use "Waiting for cache lock: %s" instead of "... (%s)", as having
multiple sentences inside parenthesis is super weird, as is having two closing parens.
We pass the information via _config, as that's reasonably easy and avoids
ABI hackage. It also provides an interesting debugging tool for other
kinds of progress.
|
| |
|
|
|
|
| |
This is a rework of !6 with additional stuff for the frontend
lock, so we can lock the frontend lock and then keep looping
over dpkg lock.
|
| |
|
|
|
| |
This is the first step. Next step will be to add warnings to
apt-get and then remove support there as well.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
As long as we are running dpkg, keep an inhibitor that
blocks us from shutting down.
LP: #1820886
|
| |\
| |
| |
| |
| | |
Set PATH=/usr/sbin:/usr/bin:/sbin:/bin when running dpkg
See merge request apt-team/apt!38
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This avoids a lot of problems from local installations of
scripting languages and other stuff in /usr/local for which
maintainer scripts are not prepared.
[v3: Inherit PATH during tests, check overrides work]
[v2: Add testing]
|
| |/
|
|
|
|
|
|
|
| |
This allows us to install matching auth files for sources.list.d
files, for example; very useful.
This converts aptmethod's authfd from one FileFd to a vector of
pointers to FileFd, as FileFd cannot be copied, and move operators
are hard.
|
| |
|
|
|
|
| |
Not needed for common interactions, but for some download-file
interactions it could be useful to set a specific referer as some
servers do not serve requested files otherwise.
|
| |
|
|
| |
Closes: #910941
|
| |
|
|
|
| |
120s is an insanely high default time out, lower it to 30s
to make things a bit nicer.
|
| |
|
|
| |
Prompted-by: Jakub Wilk <jwilk@debian.org>
|
| |
|
|
|
|
|
| |
zstd is a compression algorithm developed by facebook. At level 19,
it is about 6% worse in size than xz -6, but decompression is multiple
times faster, saving about 40% install time, especially with eatmydata
on cloud instances.
|
| |\
| |
| |
| |
| | |
Check that Date of Release file is not in the future
See merge request apt-team/apt!3
|
