On 15.05.2023 15:19, Vincent Lefevre wrote:
On 2023-05-15 10:25:45 +0500, Alexander V. Makartsev wrote:
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?
Well, if you don't want the "deb" part, you need to provide the
name of the source package directly to "apt source". If you do that
frequently, you can write a script. There are 2 solutions:
* A remote request, e.g. with rmadison.
* Something based of "apt cache show". From that, you can get the
source package, then call "apt source" with the source package.
But note that this is only a heuristic; if the name of the source
package has changed from stable to testing, this won't work.
Note that adding the "deb" part shouldn't be much an issue (except
noise, e.g. with "apt cache show", which would give output for both
stable and testing). If you want to make sure that a package from
testing won't be installed by mistake (by apt), I suppose that you
can use apt preferences with a negative priority for testing to
prevent such an installation:
Package: *
Pin: release a=testing
Pin-Priority: -1
(not tried). See the apt_preferences(5) man page for details.
It looks like adding the "deb" part with apt pinning is the best option.
Even with pinning in effect, packages from "testing" still could be
installed, but only if they were manually requested.
Now the command "$ apt source lego/testing" is working properly.
Thanks for suggestions, Vincent.
--
With kindest regards, Alexander.
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system
⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org
⠈⠳⣄⠀⠀⠀⠀
