| Commit message (Collapse) | Author | Age | Files | Lines |
| | |
|
| | |
|
| |\
| |
| |
| |
| | |
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]
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
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
|