Man page of apt-cache dont mentions regex on operations with pkg argument
,except from 'search'


But i tested in wheezy and i see that using regex with operation like show ,
showpkg  works.

Is there a recommended way to request a literal package name match from
apt-cache show?

In reportbug we are parsing the output of apt-cache show to obtain
information on available packages. This does not always work correctly
if the package name includes "+" or ".", see #1031924 for an example bug
report.

Should we just re.escape() the package name before passing it to
apt-cache show? Or is there a risk of this breaking with future versions
of apt (e.g., if apt is changed to address #776840)?

(For reportbug I think we could also solve it by making more use of
python-apt.)

Thanks!

(For MultiArch – merged around 0.8 in 2010 – I rewrote the command line
 parsing for all tools to have them all behave somewhat similar. The
 bigger ones like 'show' "always" supported regex, but it e.g. didn't
 handle "foobar:armel/experimental" and I didn't want to write
 more or less the same thing 10+ times. The documentation always only
 speaks about package names for those commands even through you could
 even back than do a lot of other things as well… the docs never
 mentioned all of this all to explicitly in a lot of places. Honestly,
 I think most users couldn't handle the truth, but our docs are just
 in general in need of a revamp, so perhaps some day I am proven wrong
 by someone who rewrites them)
apt-cache show '?exact-name(vera++)'

Note that in a Multi-Arch context multiple packages with that exact name
exist – e.g. vera++:amd64 and vera++:i386, so you might have to make
further selections with more patterns. I don't really use them, so not
really much of an expert on them. See apt-patterns(7).


That selection is done for you if you do 'apt-cache show vera++' as it
will assume that you are interested in information for the package
which would be installed if you were doing 'apt-get install vera++'.
(Yes, that is a recursive definition)

That works, because 'vera++' is a real binary package name and apt
checks if a package with that name exists before it tries regex matches
or assumes the postfix '+' is a modifier indication that this package
should be installed (aka: apt-get remove vera+++ # installs vera++).

That means that if what you provided is for whatever reason not a real
binary package name apt goes looking for what you could have possibly
meant, similar to how 'install' goes looking for what you might have
meant, like a package from another architecture with that name or
a glob, a regex, a task or a single-provider of a virtual package, …

To use Simons examples from #1031924 (reordered for my benefit):

| freefem++ -> (correct)
| hello -> (correct)

is an existing binary package (that it is also a source
package name is of no concern for 'show')

| dbus-c++ -> dbus-cpp
| gtk+2.0 -> librcc
| lucene++ -> lucene-solr
| gtk+3.0 -> wxpython3.0

is a source package, no binary package with that name exists.  apt
interprets them hence as regexes and so likely multiple stanzas for
multiple matching packages are produced. Funnily enough gtk+3.0 doesn't
even produce binary packages which match (while gtk+2.0 does, but both
just as sidenote, it makes no difference for apt).

| gtk4 -> (correct)

Neither an existing binary nor a regex or anything else apt can
make sense of, so no package can be found. I presume reportbug has
a fallback or whatever which ends up doing the right thing for source
packages?


Arguably, providing a source package name to reportbug is incorrect
usage if I understand its man page right. In any case it is incorrect
usage for "apt-cache show" as it doesn't know source packages, you
would have to use "apt-cache showsrc" for those.
I commented on in the beginning. Indeed, going back and compiling
1.0.9.6 and running it against ~todays data gives the intended result:

~$ apt-get -v | head -n 1
apt 1.0.9.6 for amd64 compiled on Mar  9 2023 13:27:46
~$ apt-get install -s vera++
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libboost-wave1.74.0
The following NEW packages will be installed:
  libboost-wave1.74.0 vera++
0 upgraded, 2 newly installed, 0 to remove and 1 not upgraded.
Inst libboost-wave1.74.0 (1.74.0+ds1-20 Debian:unstable [amd64])
Inst vera++ (1.2.1-2+b7 Debian:11.6/stable, Debian:unstable, Debian:testing [amd64])
Conf libboost-wave1.74.0 (1.74.0+ds1-20 Debian:unstable [amd64])
Conf vera++ (1.2.1-2+b7 Debian:11.6/stable, Debian:unstable, Debian:testing [amd64])

I am therefore taking the liberty to close this referenced bugreport
via a CC of this message. The rest of this message should shine some
light on why this might have happened back in the day and what could
possible be done (nowadays). In either case, its not really a bug,
"just" a communication mismatch between users and apt-* tools which
can not be changed even if we wanted to (= foreshadowing a comment
regarding 'apt').

Also, as a side note, be careful with your shell! It might interpret
things for you as well. If all else fails btw, you can just go full
regex btw as the initial message in the bugreport already said.


apt (not apt-*) has those unanchored regexes disabled by default,
so as it is Christmas^Wfreeze I suppose you could also workaround your
problem in reportbug with a little config option:

| $ apt-cache show dbus-c++ | grep -e ^Package: | wc -l
| 28
| $ apt-cache show dbus-c++ -o APT::Cmd::Pattern-Only=true
| N: Unable to locate package dbus-c++
| E: No packages found
| $ apt-cache show vera++ -o APT::Cmd::Pattern-Only=true
| Package: vera++
| Source: vera++ (1.2.1-2)
| […]

The option is undocumented, so we might drop it at some point, but
I guess its not very likely to happen now or anytime soon if at all,
so it should be good enough as a workaround until you fix the underlying
problem in reportbug.

That is probably a good idea as, as you can see, the command line
interfaces are more concerned with trying to making sense of what the
user might have meant with its (incomplete) input rather than being 100%
machine predictable. That apt-* are used in a lot of scripts doesn't
change that, it makes it in fact worse, as changing the behaviour is
impossible without breaking others.


Best regards

David Kalnischkies