Re: Bug#1021425: debmany: "The package does not exist" when in exists in cwd
Control: clone -1 -2
Control: reassign -2 apt 2.5.3
Control: retitle -2 apt: Should provide a possibility to unconditionally show the download URI of a package ("apt-get --print-uris download $pkg" no more works after "apt-get --print-uris download $pkg")
Control: found -2 2.2.4
Control: found -2 1.8.2.3
Control: found -2 1.4.11
Control: found -2 1.0.9.8.7
Control: block -1 by -2
Control: tag -1 + confirmed
Hi Jakub,
thanks for the bug report.
TL;DR: apt's "--print-uris" only prints the URI if the package still
needs to be downloaded. This is a feature with "apt-get --print-uris
install", but it is unclear if it is also considered to be a feature
in "apt-get --print-uris download". Unfortunately there seems no
possibility to make apt unconditionally show a package's download URI.
Jakub Wilk wrote:
> "debmany $pkg" fails when the package is not installed, but its deb is in
> the current working directory:
>
> $ apt-get download lolcat
> Get:1 http://ftp.debian.org/debian unstable/main i386 lolcat all 100.0.1-3 [7948 B]
> Fetched 7948 B in 0s (0 B/s)
>
> $ debmany lolcat
> ERROR: There was an error looking for package 'lolcat'.
> ERROR: The package does not exist.
Interesting. I though can't reproduce (at least on a first try):
~/tmp → debmany lolcat
[Works]
~/tmp → dget lolcat
dget: retrieving https://debian.ethz.ch/debian/pool/main/l/lolcat/lolcat_100.0.1-3_all.deb
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 7948 100 7948 0 0 57649 0 --:--:-- --:--:-- --:--:-- 58014
~/tmp → debmany lolcat
[Still works for me]
~/tmp →
> -- System Information:
> Architecture: i386
Hmmm, I tried it on amd64. But since that package is arch:all, it
really shouldn't matter. Tried it on i386 nevertheless, too, and it
worked for me as before there, too.
> Versions of packages debian-goodies recommends:
> ii sensible-utils 0.0.17
> un whiptail <none>
> ii dialog 1.3-20211214-1
> un zenity <none>
Looks good. Should choose dialog then.
So I wonder what actually triggers your condition.
Reading the code, debmany makes a difference if the package in
question is installed or not. I have lolcat installed and this is very
likely the reason why it works for me, but not for you, assuming that
you haven't installed lolcat.
And since that error message directly comes after debmany called
apt-get, it seems to be related to the "apt-get download" call inside
debmany.
So I tried these
$ apt-get download lolcat
Get:1 https://debian.ethz.ch/debian sid/main amd64 lolcat all 100.0.1-3 [7948 B]
Fetched 7948 B in 0s (124 kB/s)
$ apt-get --print-uris download lolcat
$ rm lolcat_100.0.1-3_all.deb
→ apt-get --print-uris download lolcat
'https://debian.ethz.ch/debian/pool/main/l/lolcat/lolcat_100.0.1-3_all.deb' lolcat_100.0.1-3_all.deb 7948 SHA256:28cf09021596015eb0e02eda14aec123cb462d0d0b76ddae2a8c492cbe15454d
And indeed, the latter no more shows any URIs if the package in
question already exist in the current directory. Sounds like a bug in
apt. At least no such "feature" is mentioned in the man page. (But
then again it is also not explicitly mentioned that it also works with
"apt-get download".) Hence and nevertheless reassigning and retitling
(and CC'ing the Deity list).
Interestingly I can even reproduce this issue in all old Debian
releases I still have access to, i.e. that bug either must have been
in there for ages or it is really considered to be a "feature".
But maybe it's also just a side effect of "apt-get --print-uris
install" as this logic makes actually sense there: I would expect
"apt-get --print-uris install $pkg" to only print the URIs of those
packages which are actually needed to be downloaded, especially with
regards to dependencies.
That's also the reason why debmany doesn't use "apt-get --print-uris
install" because it exactly needs one URLs and dependencies are
irrelevant.
What actually currently displays the URI for me in that directory
containing the .deb is "apt-get --print-uris reinstall lolcat". But
then again, this won't work if the package is not installed — which is
the only case when debmany actually calls "apt-get --print-uris
download".
I also tried "apt-get --print-uris --simulate download lolcat", but it
only throws the error message "E: Command line option --simulate is
not understood in combination with the other options".
But if that's all considered to be a feature for "apt-get --print-uris
download", too, we definitely need an option to reliably display the
download URI APT would use independent of the state of the requested
package on the current system as well as of the current directory.
So maybe we need an "apt-get print-uris" (or "apt-cache print-uris")
subcommand analogous to the "apt reinstall" shortcut for "apt
--reinstall install") which reliably shows that URI independent of any
current package state or downloaded files.
Or is such a possibility already present in apt and I just can't find
it even after digging through the apt-get and apt-cache man pages and
trying out commands for over an hour now?
In general I currently see these options to solve this issue:
A) In debian-goodies alone:
* Let debmany dig around in /var/lib/apt/lists/ itself.
* Let debmany parse the output of "apt-cache show $pkg" to get the
proper path on the mirror and the output of "apt-cache policy
$pkg" (or maybe better "apt-cache madison $pkg") to get the
proper mirror base URL.
Both sound like being duplicated work and error-prone — at varying
proportions.
B) In apt first, then in debian-goodies:
* Make "apt-get --print-uris download" always show the URI.
* Make "apt-get --print-uris --simulate download" work and always
show the URI.
* Create a new apt(-get|cache) subcommand "print-uris".
Let's first see what the APT developers think about this issue.
To the APT developers: Feel free to set the severity of the bug report
against apt to wishlist if you consider the current behaviour of
"apt-get --print-uris download" to be a feature and hence the addition
of another behaviour to be a feature request.
Regards, Axel
--
,''`. | Axel Beckert <abe@debian.org>, https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`- | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Reply to: