apt/test/integration/test-external-dependency-solver-protocol, branch mainDebians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=main2025-03-10T21:33:05Zedsp: Set Forbid-New-Install/Forbid-Remove: no if other is set2025-03-10T21:33:05ZJulian Andres Klodejulian.klode@canonical.com2025-03-10T17:37:55Zurn:sha1:1fc8e9eee4d6a81f907b399034f6f82da2e98140
The upgrade code may also set Upgrade: yes, and this sets both to
yes, so `apt upgrade` dumps behave like `apt-get upgrade` ones,
which of course is not intentional.
moo
edsp: Write 'Size' to the EDSP files2025-03-03T10:21:55ZJulian Andres Klodejulian.klode@canonical.com2025-03-03T10:20:52Zurn:sha1:45b04762e1990a761a7c308f9e73a286a92f908a
This allows solvers to optimize by download size; and gives us
a better means of interpreting "downloadable" debs (they must have
a size > 0 after all).
test: Fix 7 test cases for 3.0 solver, annotate others2025-02-14T18:08:45ZJulian Andres Klodejulian.klode@canonical.com2025-02-11T16:02:00Zurn:sha1:e86f3d875a48987a026f79aa4e19eeda4ad01b3b
Fix the test cases we can fix directly; add annotations where we
know what work is needed, next we'll look at the other bugs.
Write Pre-Depends with a dash again in EDSP2025-01-17T00:27:48ZDavid Kalnischkiesdavid@kalnischkies.de2025-01-17T00:01:13Zurn:sha1:4454fd246b3b7f605dcd272b2107313ba53688c5
For some reason ~ that I don't know and can't come up with on the spot ~
we output the Pre-Depends field as PreDepends in the translated
user-visible output and I accidentally copied that over to the
untranslated variant that replaced the embedded copy (with a dash)
in the EDSP generator.
Code-copies and implementation details littered all over the place are
apparently sometimes a good bug-free thing, too…
Regression-of: 6828ae2c2f9268c8187f0fa91b3c464ed84a8476
Closes: #1093254
Drop sudo-related envvars in testing framework2024-04-24T13:16:21ZDavid Kalnischkiesdavid@kalnischkies.de2024-04-23T16:13:46Zurn:sha1:9c06578c37ff77b70b9d978d48528df13e13530f
Our autoremoval-advertisment is modified by SUDO_USER as if the current
apt call was made with sudo it seems a good idea to show the ad with
sudo as well. That is annoying for our tests through as normally the
tests are run locally or by autopkgtest without sudo, but in Gitlab CI
we use it (to run our tests as user… as we are already root) and so
individual tests had to deal with this.
That is annoying and really not needed as we can have our autoremove
test check that this ad gets displayed the right way and ignore it the
rest of the time.
Avoid dealing with a fake dpkg stanza in the tests2022-09-02T14:55:45ZDavid Kalnischkiesdavid@kalnischkies.de2022-08-31T19:49:33Zurn:sha1:3498fbedafbf30e5c91deeaefa6a60d1e387593a
We needed a fake dpkg in our status file for dpkg --assert-multi-arch to
work in the past, but recent dpkg versions do not require this anymore,
so we can remove this somewhat surprising hackery in favour of better
hidden hackery we only use if we work with an older dpkg (e.g. on
current Debian stable).
Deduplicate EDSP Provides line of M-A:foreign packages2020-06-14T08:19:39ZDavid Kalnischkiesdavid@kalnischkies.de2020-06-14T07:48:29Zurn:sha1:a1464cb4025cd737ac57ea7392402d5efd2af027
M-A:foreign causes Provides to apply to all architectures and as we
wanted to avoid resolver changes for M-A those are done by explicitly
creating these provides instead of forcing the resolvers to learn about
this. The EDSP is a different beast though & we don't need this trick
here especially as it leads to needless (but harmless) duplication.
No sort+unique is done to avoid changing order (not that it should
matter, but just to be sure), but the sets should be small enough to not
make a huge difference either way.
Tell EDSP solvers about all installed pkgs ignoring arch2020-06-14T08:19:39ZDavid Kalnischkiesdavid@kalnischkies.de2020-06-13T09:45:38Zurn:sha1:419190f6c17aaf750887ec7471599681377fb01b
We usually tell EDSP solvers only about architectures we are configured
to treat as native/foreign, but the system could have packages from
other architectures installed (even if very unlikely) which could
influence the solution (e.g. requiring a removal) so we make sure to
tell them.
Do not sent our filename-provides trick to EDSP solvers2020-06-14T08:19:39ZDavid Kalnischkiesdavid@kalnischkies.de2020-06-13T09:36:41Zurn:sha1:71d753b5e450a99f7f6677fe4899515aaec7e585
If package is installed via an explicitly given deb file we store the
filename as a provides, so that the frontend can request the filename
and get the usual "Selected foo instead of foo.deb" message.
We do not need to trouble the EDSP solvers with that though as these
provides are not valid in various ways and we have already solved the
link between commandline and package (and version) for them.
Closes: #962741
ensure generation of valid EDSP error stanzas2016-12-31T01:29:20ZDavid Kalnischkiesdavid@kalnischkies.de2016-12-29T10:20:18Zurn:sha1:0161280405fe5aa256dc9df6a56106dd3a1a6f38
The crude way of preparing a message to be a multiline value failed at
generation valid deb822 in case the error message ended with a new line
like the resolving errors from apt do. apt itself can parse these, but
other tools like grep-dctrl choke on it, so be nice and print valid.
Reported-By: Johannes 'josch' Schauer on IRC