On 15.05.2023 05:43, Vincent Lefevre wrote:
On 2023-05-14 14:17:05 +0500, Alexander V. Makartsev wrote:
[...]
I think you haven't noticed that I requested for "4.9.1-1" version from
"testing" specifically,
You can't. You can either request some given version, e.g. 4.9.1-1
(but this will work only if it can be found from your local database),
or the version from some given distribution, e.g. "testing".
But my point is that your database is obsolete, because if you ask
the version from testing, apt thinks that it is 3.2.0-3.1, while it
should be 4.9.1-1. You need to fix that.
What is the best approach to fix that? Keep in mind, I only need a
source package(-s) from "testing".
So, just to be safe, "deb" source for "testing" was commented out:
$ cat /etc/apt/sources.list | grep -iE "testing"
#deb https://deb.debian.org/debian/ testing main contrib non-free
deb-src https://deb.debian.org/debian/ testing main contrib non-free
hence why the command was "$ apt source lego/testing" not just "$ apt source
lego".
There is no reason for building a backport package for "stable" using a
source package from "stable"...
I've changed all my repo mirrors to "deb.debian.org" suspecting the previous
mirror I used was somehow out-of-date. Why is my output differ from yours?
$ apt-show-versions -a lego
lego:amd64 3.2.0-3.1+b5 bullseye deb.debian.org
No proposed-updates version
No stable-updates version
No testing version
No unstable version
lego:amd64 not installed
lego:i386 3.2.0-3.1+b5 bullseye deb.debian.org
No proposed-updates version
No stable-updates version
No testing version
No unstable version
lego:i386 not installed
After changing your sources.list, you need an "apt update" again.
Of course, I always do "$ sudo apt update" after changing apt config
files and before any package manipulation.
Yet "rmadison" reports there is a version "4.9.1-1" available in "testing":
$ rmadison lego
lego | 0.3.1-5+b13 | oldstable | amd64, arm64, armel,
armhf, i386, mips, mips64el, mipsel, ppc64el, s390x
lego | 3.2.0-3.1+b5 | stable | amd64, arm64, armel,
armhf, i386, mips64el, mipsel, ppc64el, s390x
lego | 4.9.1-1 | testing | amd64, arm64, armel,
armhf, i386, mips64el, mipsel, ppc64el, s390x
lego | 4.9.1-1 | unstable | amd64, arm64, armel,
armhf, i386, mips64el, mipsel, ppc64el, s390x
I suspect "apt-show-versions" output is inconsistent because I only request
"deb-src" from "testing" in "sources.list", as I've shown before.
Probably. "apt-show-versions" considers only the binary packages
(but "lego" is only a binary package).
I see. "rmadison" utility is checking out repos directly, where as
"apt-show-versions" rely on local database information.
[...]
I did some additional research and I think I got it.
"lego" package is special because its source package is named differently:
Yes, as said by apt above:
Picking 'golang-github-xenolf-lego' as source package instead of 'lego'
[...]
But why "apt" doesn't play along, since it knows the source package for
"lego" has different name, but ignores the "testing" part of the request?
$ apt source lego/testing
Reading package lists... Done
Picking 'golang-github-xenolf-lego' as source package instead of 'lego'
E: Can not find version '3.2.0-3.1' of package 'lego'
E: Unable to find a source package for golang-github-xenolf-lego
Looks like an "apt" bug to me.
Probably not. You are doing a request on a binary package (since
"lego" is not a source package). The translation from the binary
package to the source package depends on the particular version of
the binary package. So lego/testing will correspond to the binary
package from testing, which is 3.2.0-3.1+b5 in your case (because
of your obsolete database due to the missing "deb" for testing in
sources.list). Then apt translates this to the source package (of
the same version) golang-github-xenolf-lego 3.2.0-3.1, which is
unknown on your machine because the deb-src database is up-to-date
(contrary to the deb database). Something like that.
I see. That explains why I can request source package
"golang-github-xenolf-lego/testing" directly and get the right one.
So, in my case, I won't be able to reliably get a source package(-s)
from "testing" if I don't add "deb" part of "testing" to "sources.list",
which could be a different can of worms...
Is this something for me to just be aware of and leave it as is now, or
is there more elegant solution?
--
With kindest regards, Alexander.
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀
