| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
| |
Schedule all other binaries in the source package for upgrade if
the candidate version belongs to the same source version as the
package we are upgrading.
This will significantly reduce the risk of partial upgrades and
should make life a lot easier.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently the solver handles cases where a Breaks b (<< 1) and
if we install that a, upgrades b. However, where b Depends a (= 1),
b was removed again.
This addresses the problem by iterating over installed reverse
dependencies of upgrades and upgrading them so that both cases
work roughly similarly.
LP: #1974196
|
| |
|
|
|
|
| |
Pass some package names to upgrade to see that that works
Gbp-Dch: ignore
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
If a package is already pinned to a negative value, we should not
override this with a positive 1. This causes packages to be installable
that were pinned to -1, which is not intended.
For this, implement phasing as a ceiling of 1 for the pin instead
of a fixed 1 value. An alternative would have been to fix it to
NEVER_PIN, but that would mean entirely NEW packages would not be
installable while phasing which is not the intention either.
LP: #1978125
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
Some of our headers use APT_COMPILING_APT trickery to avoid exposing too
broadly details we don't want external clients to know and make use of.
The flip-side is that this can lead to different compilation units
seeing different definitions if they aren't all using the same config.
|
| |
|
|
|
|
|
|
|
|
| |
We use 'stty sane' to combat against stepped output and co caused by
(especially) failed tests, but it does so many things that it
occasionally fails to reset some bits in the parallel interaction we
have with it which fails the tests without a real problem in apt…
Ideally we would be better at stitching the output together, but for the
time being lets ignore these failures instead to stabilize the tests.
|
| |
|
|
|
|
| |
Building the library just so we can build the helpers against it is not
only wasteful but as we are supposed to test the system we can use that
as an additional simple smoke test before the real testing starts.
|
| |\
| |
| |
| |
| | |
Consistently dealing with fields via pkgTagSection::Key
See merge request apt-team/apt!233
|
| | |
| |
| |
| |
| |
| |
| | |
We abstract hashes a fair bit to be able to add new ones eventually,
which lead us to building the field names on the fly. We can do better
through by keeping a central place for these names, too, which even
helps in reducing code as we don't need the MD5 → Files dance anymore.
|
| | |
| |
| |
| |
| |
| | |
The dependency relation fields old names were deprecated in 1995
as the new ones were introduced. That seems barely long enough now
as a transition period.
|
| | |
| |
| |
| |
| | |
dpkg-dev stopped recognizing it in 2007 (1.14.7) while building packages.
The rename itself happened in 1995 (0.93.72).
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous regime of the file was to sort it on insert, but that
changes the values in the generated enum, which is fine as long as we
only use it in libapt itself, but breaks on other users.
The header was always intended to be private to apt itself, so we just
document this here now and lay the ground work to have the file in the
future only appended to, so that it remains sufficiently ABI stable that
we can use it outside the library in our apt tools.
We also remove some fields apt is unlikely to need or only uses in
certain cases outside of any (speed) critical path to have enough room
to add more fields soon as currently we are limited to 128 fields max
and it would be sad if we use up that allowance entirely already.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The hack is 7 years by now, so in an attempt to make that slightly
cleaner lets move this to proper variables that can be assigned via
an extra-environment file sources by the framework rather than relying
on my user name and locate in public.
Gbp-Dch: Ignore
|
| | |
| |
| |
| |
| |
| |
| | |
It happens to the best, so it might happen for us, too, one day.
Better to catch it directly instead.
Gbp-Dch: Ignore
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
The kernel autoremoval algorithm was written to accomodate
for Ubuntu's boot partition sizing, which was written to
accomodate 3 kernels - 2 installed ones + a new one being
unpacked.
It seems that when the algorithm was designed, it was overlooked
that it actually kept 3 kernels.
LP: #1968154
|
| |
|
|
|
|
|
| |
apt/test/interactive-helper/aptwebserver.cc: In function ‘std::string HTMLEncode(std::string)’:
error: variable ‘constexpr const std::array<std::array<const char*, 2>, 6> htmlencode’ has initializer but incomplete type
Reported-By: Helmut Grohne on IRC
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a repository is signed with multiple keys, apt 2.4.0 would
ignore the fallback result if some keys were still missing,
causing signature verification to fail.
Rework the logic such that when checking if fallback was "succesful",
missing keys are ignored - it only matters if we managed to verify
one key now, whether good or bad.
Likewise, simplify the logic when to do the fallback:
If there was a bad signature in trusted.gpg.d, do NOT fallback at all
- this is a minor security issue, as a key in trusted.gpg.d could
fail silently with a bad signature, and then a key in trusted.gpg
might allow the signature to succeed (as trusted.gpg.d key is then
missing).
Only fallback if we are missing a good signature, and there are
keys we have not yet checked.
|
| |
|
|
|
| |
With apt-key going away, people need to manage key files, rather
than keys, so they need to know if any keys are in the legacy keyring.
|
| |
|
|
|
|
|
|
|
| |
Our EDSP code is confused by the spaces in the package name, so we adopt
a naming scheme similar to build-dep here instead of trying to teach
EDSP to somehow encode the spaces as that is probably even more
confusing for onlookers than this invalid package name is.
Reported-By: Johannes Schauer Marin Rodrigues on IRC
|
| |
|
|
|
|
|
|
| |
The -q flag isn't quiet – it means quick – so ar happily prints an
"ar: creating test.deb" which is harmless, but also pointless and it
is the only testcase who produces output.
Gbp-Dch: Ignore
|
| |
|
|
|
|
|
|
| |
Pinning and its display was reworked years ago, but the test and
especially the comment never got the memo.
References: a91aae406112df1d8fe16d00212333a20210f674
Gbp-Dch: Ignore
|
| |
|
|
|
|
| |
I have no idea what I was thinking 12 years ago.
Gbp-Dch: Ignore
|
| |
|
|
|
|
|
|
| |
GNU parallel diverts moreutils implementation away. As we us moreutils
features just installing parallel breaks the test runner hence. We have
this already for another naming scheme, so fixing this is easy enough.
Gbp-Dch: Ignore
|
| |
|
|
|
| |
This adds back the missing fields that we do not show any
other way.
|
| |
|
|
| |
Package: field
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Debian 11 release notes elevate matching with regex to a documented
and much used feature, which it previously wasn't. For binary packages
this is not a problem, but source packages are special and it turns out
that matching by release is here an exact string match only.
A bit of refactoring later we can reuse the code we use for Packages
files also for Release files, which is what we have for Sources files as
those files itself have no representation in the cache.
This means that we do not support matching based on components (c=main)
in source, but we didn't before and we can cross that bridge if anyone
notices…
Closes: #998444
|
| |
|
|
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| | |
Allow =version and /release selectors on virtual packages
See merge request apt-team/apt!121
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We already have code for figuring out if a virtual package is only
provided by a single provider (and otherwise show a list) we can
auto-select for the user, so we can adapt that to work with versioned
provides as well and while at it also release selectors.
The code tries to keep ABI backward compatible and hence turns
relatively ugly as we need a parameter (the selector) to be passed
around without adding a parameter or new virtual methods.
|
| | |
| |
| |
| |
| | |
Edgecase of an edgecase at best, but it works just fine as a dependency,
so it should really work on the commandline as well.
|
| | |
| |
| |
| |
| |
| | |
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
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
RFC7233 3.2 If-Range specifies the comparison to be an exact match,
not a less or equal, which makes no sense in this context anyhow.
Our server exists only to write our tests against it so this isn't much
of a practical issue. I did confirm with a crashing server that no test
(silently) depends on this or exhibits a different behaviour not
explicitly checked for.
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Debian buster (oldstable) ships 6.1 while bullseye (stable) ships 6.5
and so the later is 'fixed'. Upstream declares 6.0 still as supported.
It might be still a while we encounter "bad" versions in the wild, so
if we can detect and work around the issue at runtime automatically we
can save some users from running into "persistent" partial files.
References: https://varnish-cache.org/docs/6.4/whats-new/changes-6.4.html#changes-in-behavior
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Fix file:/// vs file:/ hang & https-proxy for http
See merge request apt-team/apt!187
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The settings used for unwrapping TLS connections depend on the access
and hostname we connect to more than what we eventually unwrap. The
bugreport mentions CaInfo, but all other https-settings should also
apply (regardless of generic or hostname specific) to an https proxy,
even if the connection we proxy through it is http-only.
Closes: #990555
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We allow file (and other file-based methods) URIs to either be given
as file:///path or as file:/path, but in various places of the acquire
system we perform string comparisons on URIs which do not handle this
expecting the canonical representation produced by our URI code.
That used to be hidden by us quoting and dequoting the URIs in the
system, but as we don't do this anymore we have to be a bit more careful
on input.
Ideally we would do less of these comparisons, but for now lets be
content with inserting a canonicalisation early on to prevent hangs in
the acquire system.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
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
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
What does a M-A:allowed package from non-native/non-foreign architecture
provide? If we look at M-A:foreign, such a package satisfies
dependencies within its own architecture, but not in other
architectures, so the same should apply to :any dependencies on
M-A:allowed packages, but we have a problem: While unqualified package
names are architecture-specific, the virtual package name qualified with
:any is not (see 3addaba1ff).
We could of course make it architecture-specific now, but that would
introduce many virtual packages for this relatively minor usecase and
would reintroduce a need for special display handling.
So, we pull a trick here: Barbarian M-A:allowed packages do not provide
the architecture-independent :any package anymore, but only a specific
one and every :any dependency from a barbarian package is rewritten to
an or-group of the specific and the independent :any package.
References: 3addaba1ff
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As we don't know which architectures we will deal with and to avoid
creating many "unneeded" packages (and provides) the cache
generation uses a scheme of on-demand creation (see ecc138f858).
This assumed a particular handling of :any which got changed later
(3addaba1ff) making this code path not only no longer needed for
M-A:allowed, but actually wrong as it would go on and create provides
for the explicit Provides of a package as if the package would be
M-A:foreign.
The result was that a package A:amd64 providing B tagged as M-A:allowed
would satisfy a "C:armel depends on B". Note that this bug does NOT
effect "C:armel depends on A" which is (correctly) not satisfied as
before.
References: ecc138f858, 3addaba1ff
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Back than M-A was added to build-dependencies (#558104) only the
qualifiers :native and :any were considered at first which for the
native case behave the same, so stripping was a good idea.
Nowadays we could encounter arch-qualified dependencies, too, through –
or slightly more likely conflicts perhaps – at least in theory as in
practice native build-dep operations in Debian and elsewhere wouldn't
have other architectures available anyhow.
Still, we have full support for all this for the crossbuilding case
which makes active use of this (at least is far more likely to do so),
so it seems better to converge on one edgecase rather than keeping
two in active use and so produce potentially different results for not
specifying -a and -a $native.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
APTs ad hoc testing framework for integration tests is not intending to
be a general propose framework, but it is relatively easy to abuse it
for other projects anyhow with some refactoring even if that is neither
recommend nor officially supported.
Gbp-Dch: Ignore
|
