On Wed, 12 Oct 2022, Stefan Seefeld wrote:
On Wednesday, 12 October 2022 at 01:10:06 UTC-4, tomas wrote:
Try doing "apt-cache policy Y", that might shed light on this.
This reports
```
Y:
Installed: (none)
Candidate: 1.0.3
Version table:
1.0.3 500
500 <repo> focal/main amd64 Packages
1.0.1 500
500 <repo> focal/main amd64 Packages
```
(I'm running on Ubuntu 20.04, using apt-get=2.0.6)
(Isn't there a Ubuntu mailing list, btw? They might be doing funny stuff
with their packaging which perhaps change the problem space)
The repo is actually our own in-house repo (managed via artifactory).
Are there any clear semantic rules spelled out in some document that govern what should happen ?
I'm surprised that if my package "X" has specific and unambiguous dependencies on an
existing package "Y", and that version exists in the repo, it should be installed. Am I
missing something ?
In your original command you had X as a file on the commandline. Does it
work when X is in a repo?
I have my own repo and I've had no issues like this.
$ apt-mark showauto | grep dump
dump
$ apt-mark showmanual | grep backup
backup
$
Is there something strange about what release or architecture X thinks
it is in? Perhaps that is why apt won't autoinstall Y but Y can satisfy
X's dependencies.
This file has all the debugging options for apt:
/usr/share/doc/apt/examples/configure-index
-o Debug::pkgProblemResolver=yes might show something. (that's a guess,
I've not used this option)