Acknowledgement sent
to Nicholas Brown <[email protected]>:
New Bug report received and forwarded. Copy sent to APT Development Team <[email protected]>.
(Tue, 29 Jun 2021 12:42:03 GMT) (full text, mbox, link).
Package: apt
Version: 1.8.2.3
'apt-cache showpkg' can be constrained to only show the version that will
be installed by using the '--no-all-versions' option.
It would be useful to have an equivalent option for 'apt-cache showsrc' so
that it only shows the version of the source package that would be
installed, instead of all available versions.
Acknowledgement sent
to Chandler Sobel-Sorenson <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
Your message did not contain a Subject field. They are recommended and
useful because the title of a Bug is determined using this field.
Please remember to include a Subject field in your messages in future.
I concur and also request `--no-all-versions` apply to `apt-cache
policy` command as well.
Perhaps, instead, a new option with argument `--versions=N` could be
implemented, allowing a limited number of versions to be returned, with
`--versions=0` or `--versions=none` being the equivalent of
`--no-all-versions`.
Acknowledgement sent
to David Kalnischkies <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Wed, 13 Mar 2024 09:39:02 GMT) (full text, mbox, link).
On Wed, Mar 13, 2024 at 12:35:14AM -0700, Chandler Sobel-Sorenson wrote:
> I concur and also request `--no-all-versions` apply to `apt-cache
> policy` command as well.
What would this achieve; what is the use case?
I literally see no point in having 'policy' limited to a single version
(and which one?) given its usually used to show which versions are
available from where, how the pin values are for those and which one is
considered the candidate as a result of that.
> Perhaps, instead, a new option with argument `--versions=N` could be
> implemented, allowing a limited number of versions to be returned, with
> `--versions=0` or `--versions=none` being the equivalent of
> `--no-all-versions`.
Uhm… beside that the --no-all-versions flag switches the display from
"display all versions" to "display the candidate version only" in e.g.
'show' (and one or the other is the default in apt-cache vs. apt), so
the equivalent would be more like '1' … and '0' would display nothing?
How would --versions=3 behave through: Assuming I have 5 different
versions available in the sources, which of these are displayed and
which are not… regardless of the choice, this seems rather unintuitive
to discover without many paragraphs of documentation that basically
duplicates the code in prose text.
Again, what would this achieve and what is the use case for this?
Sidenote: If a specific task has no people interested in working on
it, its not a good idea to add additional tasks as that is the moral
equivalent of saying: "Nobody bought it for 5€, lets ask for 20€"¹.
Either create a compelling new task referencing related ones or much
better yet do work on it yourself. Its open source after all and nothing
will ever get done if everyone hopes someone else will do it.
Best regards
David Kalnischkies
¹ well, I suppose for e.g. life style products that might work, but
somehow I doubt we can "sell" requests as a life style product…
Acknowledgement sent
to Chandler Sobel-Sorenson <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Sat, 16 Mar 2024 02:27:02 GMT) (full text, mbox, link).
David Kalnischkies wrote on 3/13/24 2:28 AM:
> What would this achieve; what is the use case?
The use case is when a repo has too many versions of a software on it.
I'd only be interested in seeing the details for the Installed and
Candidate versions, so even my initial --versions suggestion is not good
enough for that.
> I literally see no point in having 'policy' limited to a single
> version (and which one?) given its usually used to show which versions
> are available from where, how the pin values are for those and which
> one is considered the candidate as a result of that.
Maybe just the candidate version? Who knows? Chances are someone would
find it useful.
> Uhm… beside that the --no-all-versions flag switches the display from
> "display all versions" to "display the candidate version only" in e.g.
> 'show' (and one or the other is the default in apt-cache vs. apt), so
> the equivalent would be more like '1' … and '0' would display nothing?
Precisely, for those of us looking for a little more zen in our lives.
> How would --versions=3 behave through: Assuming I have 5 different
> versions available in the sources, which of these are displayed and
> which are not… regardless of the choice, this seems rather unintuitive
> to discover without many paragraphs of documentation that basically
> duplicates the code in prose text.
Now is this 5 repos with 1 version each, or 2 repos with 2 versions plus
1 repo with 1 version, or 1 repo with 5 versions, or 3 repos with 1
version plus 1 repo with 2 versions, or 1 repo with 1 version plus 1
repo with 4 versions?
Will --versions apply on a per-repo basis or globally?
We could go down a list of priorities until the number of desired
versions has been reached, that could include: Installed, Candidate,
Candidate-1, Installed+1, Installed-1, Candidate-2, Installed+2,
Installed-2, et cetera, et cetera
> Again, what would this achieve and what is the use case for this?
Likely the same or similar reasons --no-all-versions already exists, for
one to limit the clutter and undesirable information on our screens, et
cetera, et cetera.
> Sidenote: If a specific task has no people interested in working on it,
There're categories for such tasks such as "closed" or "wontfix" et
cetera, et cetera, none of which apply to this request as of yet.
> Either create a compelling new task referencing related ones
Such was of course considered but this path was chosen in our infinite
wisdom. We're sure you'd've complained either way, saying it's a
duplicate and how kilobytes of bandwidth and storage were wasted,
right? Et cetera, et cetera.
> or much better yet do work on it yourself.
Our time is quite limited and you're blessed to have received this much
of it already.
> Its open source after all and nothing will ever get done if everyone
> hopes someone else will do it.
It is? -squints- Our Gods! You're right, all this time wasted sharing
our ideas for improvements when we could've just done it ourselves,
silly us! Why are there even mailing lists?
Decades of work, lost! The travesty! Just think where we could be by
now, et cetera, et cetera...
Fax mentis incendium gloriæ culpum et cetera, et cetera...
Memor bis punitor delicatum!
> Best regards
You sure?
Acknowledgement sent
to David Kalnischkies <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Sat, 16 Mar 2024 09:12:03 GMT) (full text, mbox, link).
On Fri, Mar 15, 2024 at 07:24:32PM -0700, Chandler Sobel-Sorenson wrote:
> David Kalnischkies wrote on 3/13/24 2:28 AM:
> > What would this achieve; what is the use case?
> The use case is when a repo has too many versions of a software on it.
> I'd only be interested in seeing the details for the Installed and
> Candidate versions, so even my initial --versions suggestion is not good
> enough for that.
So, your request is to add a saw-blade to a hammer just in case you
might have a need for tree chopping with policy some day?
If you are about details about specific versions, I would suggest using
e.g. "apt show foo=version" or "apt show foo" (= that displays only info
about the candidate) or "apt show foo/now" (= currently installed). Or
go crazy with some apt-patterns(8).
Or, you use "apt-cache show foo" (for info about all versions) and
select with some (dctrl-)grep'ing.
> […]
> Fax mentis incendium gloriæ culpum et cetera, et cetera...
>
> Memor bis punitor delicatum!
Omnia dicta fortiora si dicta Latina.¹
I wasn't quiet sure if you are serious or not, but I see now that you
are indeed just trying to troll. Very funny. Did I pass the test now?
Can't wait for my life time supply of chocolate, Mr. Wonka.
Reference: https://yewtu.be/watch?v=WW2qaBJWdaA (many more videos show
a bit more or less of the scene – that one just has hard coded subs;
spoiler alert for "Willy Wonka & the Chocolate Factory" from 1971 …)
> > Best regards
> You sure?
"You lose! Good day, Sir."
David Kalnischkies
¹ everything sounds more impressive when said in Latin
Subject: apt: the --no-all-versions option not working as documented
Date: Thu, 2 May 2024 12:40:30 +0200
Package: apt
Version: 2.6.1
Followup-For: Bug #990451
X-Debbugs-Cc: [email protected]
I just ran into this problem.
Scenario: I am on a limited internet connection. So if I do “aptitude
install $somepkg” which then pulls in many other packages, I need to
know which packages will be fetched from the cloud and which are
sourced from my local storage (which is the full 90gb debian release
from 4 months ago). If the download is big, it will suck the bandwidth
quota dry (which costs money).
So I tried this:
$ while read -d ' ' pkg; do apt-cache policy --no-all-versions "${pkg%%{*}"; done <\
<(yes | aptitude install $some_pkg --simulate | sed -ne '/^ /p')
non-starter:
===8<----------------------------------------
E: Command line option --no-all-versions is not understood in combination with the other options
E: Command line option --no-all-versions is not understood in combination with the other options
E: Command line option --no-all-versions is not understood in combination with the other options
E: Command line option --no-all-versions is not understood in combination with the other options
…
===8<----------------------------------------
There is a bug here no matter what, because the man page does not
disclose the narrow scope by which --no-all-versions applies. It took
trial and error with several apt-cache commands before it became
evident that it only works on the “apt-cache show” command. The show
command does not give the information needed. That is, it does not
indicate the location where the candidate version will be sourced
from.
My workaround hackery is this:
$ while read -d ' ' pkg; do apt-cache policy -o APT::Cache::AllNames=false "${pkg%%{*}"; done <\
<(yes | aptitude install $some_pkg --simulate | sed -ne '/^ /p') |
sed -ne '/^[a-z]/Ip;/Version.table/{N;N;p}'
Note that “-o APT::Cache::AllNames=false” is used in vain (it has no
effect but at least it does not interfere either). The work of
suppressing the non-candidate noise is done by the last sed command.
It would be nice if I could also get a total size on any files to be
fetched. My knee-jerk thought would be to filter on all packages that
are not sourced from file:/local/filesystem, run apt-cache on that
subset to get full URLs, then do something like:
apt-cache show "$pkg" | awk '/^Size/{print $2}'
Anyway, the low-effort fix would be to at least update the man page to
state the narrow availability of --no-all-versions. Though it would be
useful if it worked for policy.
In light of my use case, you could also say it’s already hacking
territory that apt-cache was needed at all. In principle, aptitude’s
installer output of how much data will be fetched should give a
breakdown of data volume to be fetched from each source location,
perhaps when run in a verbose mode.
-- System Information:
Debian Release: 12.5
APT prefers stable-updates
APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-28-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages apt depends on:
ii adduser 3.134
ii debian-archive-keyring 2023.3+deb12u1
ii gpgv 2.2.40-1.1
ii libapt-pkg6.0 2.6.1
ii libc6 2.36-9+deb12u6
ii libgcc-s1 12.2.0-14
ii libgnutls30 3.7.9-2+deb12u2
ii libseccomp2 2.5.4-1+b3
ii libstdc++6 12.2.0-14
ii libsystemd0 252.22-1~deb12u1
Versions of packages apt recommends:
ii ca-certificates 20230311
Versions of packages apt suggests:
pn apt-doc <none>
ii aptitude 0.8.13-5
ii dpkg-dev 1.21.22
ii gnupg 2.2.40-1.1
ii powermgmt-base 1.37
-- no debconf information
Acknowledgement sent
to David Kalnischkies <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Fri, 03 May 2024 11:57:04 GMT) (full text, mbox, link).
On Thu, May 02, 2024 at 12:40:30PM +0200, Manny wrote:
> Note that “-o APT::Cache::AllNames=false” is used in vain (it has no
> effect but at least it does not interfere either). The work of
I think you meant All*Versions*, not Names. The later is documented to
effect `pkgnames` only. In some way, AllVersions is documented to effect
`show`, but much less specific by "full records" – a record is what show
displays and policy doesn't, but yeah, not really discoverable.
> It would be nice if I could also get a total size on any files to be
> fetched. My knee-jerk thought would be to filter on all packages that
> are not sourced from file:/local/filesystem, run apt-cache on that
> subset to get full URLs, then do something like:
>
> apt-cache show "$pkg" | awk '/^Size/{print $2}'
>
> Anyway, the low-effort fix would be to at least update the man page to
> state the narrow availability of --no-all-versions. Though it would be
> useful if it worked for policy.
>
> In light of my use case, you could also say it’s already hacking
> territory that apt-cache was needed at all. In principle, aptitude’s
> installer output of how much data will be fetched should give a
> breakdown of data volume to be fetched from each source location,
> perhaps when run in a verbose mode.
fwiw: I don't know about aptitude and if you think it should get some
feature I suppose you should report it there, but for apt(-get) I have
to note that both display "download size" as the size of all *.deb
files to be downloaded from non-local (that mostly means non-file:/)
sources…
They do this mostly to check if the free disk space is large enough to
hold the debs to download (while file:/ are used from there they are),
but that is close at least to your knee-jerk thought.
Not sure about the later "each source location"… that can turn out to be
a lot of details for not that much gain: a typical Debian stable has
'normal', 'updates' and 'security'. You could add 'proposed' and e.g.
'backports' and a random set of 3rd parties like the typical Ubuntu user
with seemingly 42+ PPAs added. That is 3+X counters useless even to you
as you were just interested in the data coming from your local mirror
vs. others. And that would assume that all mirrors are complete and
available, no retries, no fallbacks, no redirects.
Best regards
David Kalnischkies
Acknowledgement sent
to Manny <[email protected]>:
Extra info received and forwarded to list. Copy sent to APT Development Team <[email protected]>.
(Fri, 03 May 2024 17:09:03 GMT) (full text, mbox, link).
Subject: Re: Bug#990451: apt: the --no-all-versions option not working as
documented
Date: Fri, 3 May 2024 19:06:21 +0200
> I think you meant All*Versions*, not Names.
Oh, right.. must have been a copy-paste error.
> fwiw: I don't know about aptitude and if you think it should get some
> feature I suppose you should report it there, but for apt(-get) I have
> to note that both display "download size" as the size of all *.deb
> files to be downloaded from non-local (that mostly means non-file:/)
> sources…
Thanks! That’s useful indeed.
> Not sure about the later "each source location"… that can turn out to be
> a lot of details for not that much gain: a typical Debian stable has
> 'normal', 'updates' and 'security'. You could add 'proposed' and e.g.
> 'backports' and a random set of 3rd parties like the typical Ubuntu user
> with seemingly 42+ PPAs added. That is 3+X counters useless even to you
> as you were just interested in the data coming from your local mirror
> vs. others. And that would assume that all mirrors are complete and
> available, no retries, no fallbacks, no redirects.
Indeed the cloud vs. local counts are the most useful. I was thinking
in terms of luxury. Many different sources being fetched in parallel
would give the expectation of a fast fetch. And if some are fetched
over tor or a slow host, it would also give an indication of time. And
if something comes from a Tor source and your in a place that blocks
Tor, that’s marginally useful information. But indeed the effort
would not be justfied with apt and apt-get already giving what’s
needed.
From there, I suppose my use-case does not justify making
--no-all-versions function. But the man page should at least reflect
reality.