apt/test/integration/framework, branch 2.9.0

apt: Introduce the new terse apt output format 3.0

2024-04-12T13:57:36Z

The key talking points here are: 1. Instead of long sentences, we use short concise messages, e.g. "The following NEW packages will be installed" becomes "Installing". 2. Dependencies are only listed once. We removed the "The following additional packages will be installed" section in favor of splitting up the "Installing" section into "Installing" and "Installing dependencies" (like dnf) 3. The order of the output is different: 1. Packages to be installed manually 2. Packages to be installed automatically 4. Weak dependencies of new packages not installed 3. Packages to be upgraded 4. Packages to be downgraded 5. Packages that have been kept back / are on hold 6. Removals 7. Essential removals i.e. we logically show you the action that is being done, followed by lists related to the action. 4. As requested by popey, we have colorful UI, with green for packages being installed and red for packages being removed. Caveats: - The list of recommends and suggests has not been updated yet, it should move to after the packages being installed (as they are what triggers them) This also introduces output format versioning, configured by the APT::Output-Format option. The default value is 0, except for the apt(8) binary where it is 30 - which enables the new style.

Columnar output for package lists similar to 'ls'

2024-04-12T13:56:56Z

This change makes it a bit easier to quickly grasp the changes about to be performed by apt. It displays package lists in a columnar format by default, similar to what `ls` produces for files. A new long option `--no-list-columns` and an associated `APT::Get::List-Columns` config setting control the behavior. Usage example, with 60 column wide terminal: ``` $ sudo apt upgrade | Reading package lists... Done | Building dependency tree... Done | Reading state information... Done | Calculating upgrade... Done | The following packages were automatically installed and are | no longer required: | libappindicator1 libindicator7 | libdbusmenu-gtk4 linux-image-5.14.0-4-amd64 | Use 'sudo apt autoremove' to remove them. | The following packages have been kept back: | criu linux-headers-amd64 nvidia-settings | libxnvctrl0 nvidia-modprobe xwayland | 0 upgraded, 0 newly installed, 0 to remove and 6 not upgrade| d. | ``` The effect becomes more pronounced with more packages (e.g. when doing a dist-upgrade).

Avoid subshell hiding failure report from testfilestats

2024-03-30T15:59:57Z

We remove the working directory from the found file names as these paths could contain a lot of funny characters confusing the for loop like spaces… we just readd it later in the actual calls to be safe.

Typos in integration tests

2024-01-09T16:33:58Z

Corrected 'und' -> 'and' in the fake package's description. As a result, the MD5 checksum of this string is changed from 36ef2ec58c83bc4fdbe9fe958dd9c107 to 5022766cbc9bf07d1abea2c41a72646f which in turn reduced the size of the resulting Packages.gz by one. Therefore the accepted answer in the test case is updated too.

Compare SHA256 to check if versions are really the same

2023-08-02T10:04:32Z

If we know both SHA256, and they're different, the packages are. This approach stores the SHA256 only at runtime, avoiding the overhead of storing it on-disk, because when we update repositories we update all of them anyhow. Note that pkgCacheGenerator is hidden, so we can just modify its ABI, hooray. Closes: #931175 LP: #2029268

Do not store trusted=yes Release file unconditionally

2023-03-04T12:07:00Z

A source marked with trusted=yes can still fail verification of the Release file, mostly for Date related issues, like being too new or too old, which have other options to force them in. The update code was not using the Release file (which was a InRelease file but failed verification – which was overridden by trusted=yes) as intended, but it marked it for storage, so that this "bad" Release file would end up being moved into lists/, which is bad as the indexes it refers to aren't updated while the next update run assumes that the indexes are in the state the Release file claims them to be in. Fixed simply by making the storage conditional on the usage as intended, which also resolves a second issue: The verification can also detect that a Release file we got is older than what we already have to avoid down- grade attacks. The more likely explanation is a slightly outdated mirror in a rotation/CDN through, so this gets the silent treatment to avoid scaring users by handling it as if we had got the same Release file we already have stored locally, removing the freshly received older file in the process alongside setting some variables. Those variables were already modified in the trusted=yes case though resulting in the stored Release file being removed instead. Not modifying the variables too early resolves this problem as well. Both seem to exist since at least 2015 as traces are visible in 448c38bdcd already, which shuffled lots of code around including the bad ones, but as we are in trusted=yes land, security is of no concern here, this "just" leads to failed pinning, hashsum mismatches and other strange problems in follow-up calls depending on how out of sync the Release file (if its still present) is with the rest of the trusted data. Reported-By: Dima Kogan on IRC Tested-By: Dima Kogan

Allow apt to run if no dpkg/status file exists

2022-09-02T14:55:45Z

Not having a dpkg/status file used to be a hard error which from a boostrap perspective is suspect as in the beginning, there is no status so you would need to touch it into existence. We make a difference between factual non-existence and inaccessibility to catch mistakes in which the file is not readable for some reason, the testcase test-bug-254770-segfault-if-cache-not-buildable is an example of this. Note that apt has already figured out at this point that this is a Debian-like system which should have a dpkg/status file. This change does not effect the auto-detection and is not supposed to.

Avoid dealing with a fake dpkg stanza in the tests

2022-09-02T14:55:45Z

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).

Link interactive helpers against system libapt for autopkgtest

2022-05-07T08:45:44Z

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.

Merge branch 'fix/file-https-proxy' into 'main'

2021-10-18T13:37:09Z

Fix file:/// vs file:/ hang & https-proxy for http See merge request apt-team/apt!187