`apt-get install python3.4` on xenial exits 0 despite python3.4 not being available

(This was specifically seen with the Docker image, which doesn't already have a Python installed; doing `apt-get install python3.4 python3-pip` results in python3.5 being installed, with no error.)

(srly, bugreports referring to pastebin?)

Well, apts output says what is going on: As a package with that name doesn't exist and the string looks like a regex (thanks to the '.') it will search for packages matching the regex and it does find one. That is perfectly fine and established behavior which is impossible to change without breaking existing users.

Note that the package python3.4 doesn't exist at all in the view of apt, which triggers this. If ANY package would give it as much as a passing hint that it ever existed (by having any sort of dependency on it) apt would actually error out in a way you would like it to (saying that python3.4 isn't available for install, but is referenced by other packages – pointing to the potential of being replaced by something else or distributed in another repository). That is also perfectly fine and established behavior which is impossible to change by now.

Anyway, a workaround for your setup might be using '^python3\.4$'.

So, as there is no bug to be found, closing as opinion. We could treat it as a wish for controlling how the string is interpreted, but that will actually be a tiny by-product of patterns – and is in no way helping apt versions without patterns as a feature, which is the subtext of this bugreport.

P.S.: The automation to make stuff available for an application is called packaging, not running apt commands automatically as this has failure modes like this, makes changes so much harder for the python side as well as the application side, destroys automatic removal and and and which is why package management was invented decades ago in the first place.

apt doesn't _install_ the package matching the pattern[0], because the only place it is mentioned is in the Breaks of a completely unrelated package; it isn't available to install. So the user has asked for something to be installed, and there is nothing matching their criteria available to install, and you're saying that apt shouldn't treat this as an error?

(Returning this to New, because I don't think you realised that the package that apt found wasn't installable.)

[0] The greedy pattern matching that apt employs by default _is_ terrible user experience, but that's not what I'm asking to be fixed here.

I think Dan's use case makes it clear that automatic regexp detection as apt is doing now is broken and inconsistent. You say "the string looks like a regex (thanks to the '.')" but consider that "not-a-real-package" is also a valid regex.

> The automation to make stuff available for an application is called packaging, not running apt commands automatically

The moment you need a system of multiple nodes, each with different package requirements, to function as a whole, then you lose the ability to "just use dependencies". We see this in the real world with a myriad of different solutions, all of which call apt automatically (Dockerfiles, puppet, chef, every other configuration management system out there, and of course Juju charms). So I don't think it's acceptable to Ubuntu to consider "don't use apt automatically" as an excuse for this bug. Ubuntu users use apt automatically. This isn't going away. And our users come first.

> Anyway, a workaround for your setup might be using '^python3\.4$'.

I don't think it would be reasonable for all automation everywhere to have to escape every package name in case it gets parsed as a regex.

If backwards compatibility is a problem, perhaps we can add explicit override options. For example, --parse-regex, --no-parse-regex and --guess-parse-regex, with guess being the default. Then behaviour wouldn't change, but automation could always use --no-parse-regex. Also, Ubuntu could then consider making --no-parse-regex just by shipping the desired default in /etc/apt/apt.conf.d/.

(for the record: I am not defending the name->glob->regex fallback/guess as a wonderful interface… it isn't… I am defending it on the grounds that it is an interface for nearly two decades now, so changing it for apt-get would be a horrible mess breaking usercases left and right and apt-users tend to not like that at all even if its for their own good [compare recent security enforcement]. Implementing options for changing it varying by release and even distribution is actually even more frighting than the present interface through as that one is at least reasonably consistently bad… That is why I mentioned patterns [see aptitude for examples] as a future way out - together with 'apt' on the user side, but that bug is about automation, so that will always be 'apt-get')

@Dan: Indeed, I got kinda confused by you mentioning that they got python3.5 and /not/ mentioning regex while comparing it to a non-regex in behavior. Sorry.

With no xenial box in close reach ATM I tried it (with apt 1.2 as well as 1.3 series) on my Debian machine but that has both packages available [only] in stable. Causing libpython3.4-minimal to be installed via a regex is producing the usual install behavior (it does want to remove findutils through as that breaks these. Removing essentials is fun, wouldn't be surprised if it turns out to be related to that).

Lets try the usual solver-debug-combo first: -o Debug::pkgDepCache::Marker=1 -o Debug::pkgDepCache::AutoInstall=1 -o Debug::pkgProblemResolver=1

I think we might want to have some strict mode at some point which does no automatic fallback search. Patterns also have regular expressions according to the aptitude manual, but that does not quite match the reality (aptitude install foo always installs exactly foo).

I can image we add a --exact-name option to install that only allows exact matches and does not search for similar names. That's like aptitude's ?exact-name pattern. Or we could do it the other way around and disable it by default for non-interactive use, and introduce a --force-no-exact-match-search-for-it option (and a prompt, well, just combine it into the existing prompt).