'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.

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`.

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.
"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…

David Kalnischkies wrote on 3/13/24 2:28 AM:
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.
Maybe just the candidate version?  Who knows?  Chances are someone would
find it useful.
Precisely, for those of us looking for a little more zen in our lives.
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
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.
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.
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.
Our time is quite limited and you're blessed to have received this much
of it already.
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!
You sure?

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.


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 …)

"You lose! Good day, Sir."

David Kalnischkies

¹ everything sounds more impressive when said in Latin

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.

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.

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

Oh, right.. must have been a copy-paste error.

Thanks!  That’s useful indeed.

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.