Am Sun, Sep 27, 2026 at 07:04:53AM +0700, schrieb Ross Golder: > apt silently reinstalls the identical version on every invocation when > Packages metadata diverges from the state dpkg recorded, and gives no > diagnostic and no indication that this is not an upgrade.
The bad-metadata-in-repository situation(s) you describe seem to be indistinguishable from the cases this apt 'feature' is supposed to act in. It is also not really detecting/explaining a relatively uncommon differing-metadata-due-to-differing-implementations situation. The first one is e.g. a Debian maintainer who builds the package locally and installs it for final testing before uploading. The metadata in the repository will/might be different if e.g. a dependency changed before the archive has build the package and ships it. It is "the same version", but with different metadata and yet apt will not repeatedly reinstall ~ it will just "upgrade" to the version from the archive. The second one e.g. happens if dpkg normalizes version numbers differently (or at all) compared to the tools generating the metadata for the repository. 0-Epochs are very fun in this regard for example. The repeat will be eternal, but beside the repository software(s) converging on the same normalisation, it might be faster to fix for the package maintainer to normalize it in the package… > Debian Policy 5.1 requires that continuation lines "must start with a > space or a tab", and 5.6.13 defines Description as a multiline field whose > extended description lines start with a space. Such a Packages file is > invalid. apt's parser does not report a parse error; instead > pkgTagSection::Scan looks for the terminating colon with memchr(Stop, ':', > End - Stop), which searches the whole remaining buffer rather than the > current line. The unindented line is therefore taken as a new field whose > name runs up to the next colon, which silently absorbs the Depends (or > Pre-Depends, Conflicts, Breaks, Replaces) line that follows. I suppose we could special-case multiline values in some way, so that at least some cases of this could be detected, ~ if a line does not include a colon ~, but they could of course e.g. for urls or versions with epochs. So we relatively quickly enter the domain of verification which might be too costly to do in general as the data should be fine™. In an ideal world stuff like this never happens for users as it is caught in testing by the repository maintainers. There might be a case for some sort of linter tool from the apt-realm that could catch certain problems (where stuff like doing previously said verification would be not as costly as it is paid only once, not by potentially millions of users). Such a tool (from us) doesn't exist as of yet. > debListParser::VersionHash() hashes Installed-Size, Depends, Pre-Depends, > Conflicts, Breaks and Replaces. > > With Depends absorbed, the hash of the Packages entry no longer matches > the hash computed from the same version in /var/lib/dpkg/status, so That seems a rather minor issue compared to the package not installing on a clean system (assuming it has a tiny bit more than essential dependencies) which should be the most obvious problem caused by an absorbed Depends… In practice that should not happen: Description sorts close to last in dpkg/apt-ftparchive and below dependencies in dak, too. MultiArch sorts below it in dak it seems through, which is another field that has to match. > 2. A Packages entry that omits Installed-Size. > > Debian Policy 5.3 lists Installed-Size among the fields of DEBIAN/control > without marking it "(mandatory)", and 5.6.20 only defines its meaning, so a > repository that omits it violates no rule. […] See: https://wiki.debian.org/DebianRepository/Format > (b) Reclassification: Exclude same-version reinstalls from the > Upgrade/Downgrade counts and display them in the "reinstalled" list instead. Which is a new list that you added, not an existing list like this wording suggests, so that might not change what apt does on a system level, but drastically changes the presentation and therefore might change how users (and other tools) react. > The patch does not change what apt does — the reinstall behavior is > intentional and correct when metadata diverges (it allows the cache to > converge on local package rebuilds). It only makes the situation visible and > explained. So you actually know that (local rebuilds) and yet the proposed message completely ignores that possibility and assumes another reason. So, in summary, I am not against showing those same-but-different automatic reinstalls, but I think that also includes partly-installed-or-very-bad-failures-requiring-a-reinstall. Together they might not mix well with the user-triggered --reinstall ones although all of them might be uncommon and somewhat similar enough to warrant stuffing them all into the same list. I do think trying to show a multi line notice message is (trying to) over-explaining it through, especially if it is wrong in the more common cases (still rare, but common sense dictates that "normal" usage is more common than buggy metadata that the provider doesn't test). The patch is a little … sus. Beside odd styling and dead code (e.g. DepFieldNames) the test seems to show that neither your message nor the new list is actually shown… (plus, that using testsuccessempty in this way is both disturbing and somewhat clever… but not how that is supposed to be used). Best regards David Kalnischkies P.S.: It is common courtesy to indicate the usage of AI, especially if the message text makes it somewhat obvious by its style. Bonus points for including the prompt(s) in your prompt (aka bug report).
signature.asc
Description: PGP signature
