apt interprets package names containing `-', `+' and `+' specially,
even when they are supplied as simple command line arguments.  These
characters are, of course, literals in package names, which may occur
anywhere other than at the start.

This is a problem because commands such as
   apt-get remove b.sh
   apt-get remove bonnie++
   apt-get install bonnie+.
ought to mean to operate on the specified literal package names,
regardless of whether the named packages `exist' (i.e., are known
to this instance of apt).

Otherwise it is almost impossible for a program which calls apt to
reliable `unparse' the command line: that is, to convert an intended
operation into a command line which instructs apt to always execute
the specified operation.

In some circumstances this could be a security problem.

Unfortunately this syntax is probably baked-in in some callers, so we
will have to have a transition plan.  At the very least, apt should
currently warn whenever an ambiguous string is interpreted other than
as a literal package name.

I am thinking of submitting a patch which allows ambiguous package
name specifications to be handled in one of three specified ways,
according to the configuration:
   - always treat as literal
   - always treat as literal, with warning if behaviour changed
   - current behaviour, with warning if behaviour could change

Would such a patch be welcome ?  We can then have a conversation about
what the default should be.

I would like to press ahead with this regardless of agreement on
replacement metasyntax.

Ian.

Control: severity -1 wishlist

The only time an issue can appear is if you have two or more packages
ending in + or - where one is a prefix of the other. As long as we
do not have such packages in the archive, there is no issue.

In which?

I do not agree about deprecating this just because you say you want
something else. It works just fine in practice.

If you want a replacement, how about allowing +/- prefixes
instead? That does not seem ambigous, unless I'm missing
something.

But I'm not sure it's worth the effort.

Julian Andres Klode writes ("Re: Bug#768069: apt command line package name interpretation"):
...

It can happen if anyone anywhere in the world ever creates any such
pair of packages.  apt is not just for Debian - it is for our
downstreams, too.

For example, someone could attempt to allow a user to only install
packages.  If the user requests to install a package whose name ends
in `-', the corresponding package will be removed.

Yes, +/- prefixes would work for this, but - prefixes conflict with
option names.

That `.' is a metacharacter is a problem too.

Ian.

Julian Andres Klode writes:
 I had a quick look in my (not complete) mirror and didn't see any
packages with a terminal -; however there are a number of packages with
terminal + or ++ that also have packages whose names are a prefix:

aewm       aewm++
bison      bison++
freefem    freefem++
gobjc      gobjc++
kimwitu    kimwitu++
libdb4.6   libdb4.6++
libdb4.7   libdb4.7++
libdb4.8   libdb4.8++
libdb5.1   libdb5.1++
libdb5.3   libdb5.3++
memtest86  memtest86+
minisat    minisat+
paw        paw++
python-py  python-py++
swish      swish++
vera       vera++
wmweather  wmweather+
xgalaga    xgalaga++

 In addition if there was no python-py++ package then that string
supplied to apt would match 290 packages in my mirror.

 J.