| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| | |
update: Add notice about missing Signed-By in deb822 sources
See merge request apt-team/apt!298
|
| | |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Support transition to new non-free-firmware component
See merge request apt-team/apt!282
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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).
|
| |/ |
|
| |
|
|
|
| |
since --no-allow-insecure-repositories is the default.
Signed-off-by: MichaIng <micha@dietpi.com>
|
| | |
|
| |
|
|
| |
They have been since 1.9.9, lol
|
| |
|
|
|
|
|
|
| |
This is the correct behavior, but it was overlooked when aptitude
patterns where ported. I remember wondering about this, but I checked
the aptitude code and saw a check that CurrentVer != 0 or something
and then apparently did not notice another implementation for version
matching.
|
| |\
| |
| |
| |
| | |
Do not document path to be repeatable in apt-ftparchive cmds
See merge request apt-team/apt!267
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The manpage for apt-ftparchive {packages,sources} claims that the
path argument can be repeated, but that logically conflicts with having
two optional arguments after that and isn't implemented in code either,
so we just adapt the documentation to reality here.
So, since when is this documentation wrong? The manpage is currently
written in xml (since 2004), but the sgml before that had the same
mistake included all the way back to a time in which time itself is not
stable (the commit is dated in git 2004, but the commit message
says 2001 while including a d/changelog stanza dated 2000) in
my favorite commit "Join with aliencode" which brought in a whole lot
of stuff adding also (quoting said d/changelog entry) "apt-ftparchive
the all dancing all singing FTP archive maintenance program".
In other words: It was documented this way for more than 22 years.
Reported-By: Michael Tokarev on IRC
|
| |/
|
|
| |
Closes: #1023456, #1025843
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
The documentation currently does not specify whether `apt-get download`
verifies the authenticity of downloaded packages or not. The underlying
code does verify the authenticity of packages as usual and would fail if
the package signature is invalid. Therefore it makes sense to make this
guarantee explicit in the documentation, because without it
security-conscious users will likely want to recheck the signatures or
checksums manually which is not necessary in this case and just wastes
time.
|
| | |
|
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
Rewrite phased updates using a keep-back approach
See merge request apt-team/apt!245
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/
|
|
| |
Closes: #1011315
|
| | |
|
| |
|
|
|
|
| |
Differentiating between different types of documentation we build helps
in better expressing what needs to be done for our arch:any and arch:all
packages currently as well.
|
| |
|
|
| |
Closes: #1010030
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes: #1005781
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
[jak@ Also document /etc/apt/keyrings]
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
