| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
| |
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]
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Closes: #1000424
|
| |
|
|
| |
This release is dedicated to Linus Tech Tips.
|
| |\
| |
| |
| |
| | |
Do not remove Essential/Protected due to dependencies
See merge request apt-team/apt!198
|
| | |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
| |
Closes: #998830
|
| | |
|
| | |
|
| |
|
|
|
|
| |
Extend the Signed-By field to handle embedded public key blocks,
this allows shipping self-contained .sources files, making it
substantially easier to provide third party repositories.
|
| |\
| |
| |
| |
| | |
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.
|
| |\ \
| | |
| | |
| | |
| | | |
add pattern to select packages by priority (closes: #989558)
See merge request apt-team/apt!185
|
| | | | |
|
| |\ \ \
| |_|/
|/| |
| | |
| | | |
Streamline access to barbarian architecture functionality
See merge request apt-team/apt!184
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/ |
|
| |
|
|
| |
Closes: #992352
|
| | |
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
LP: #1309658
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
