[Bug 1598810] Re: `apt-get install python3.4` on xenial exits 0 despite python3.4 not being available

[Robie Basak]

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

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to apt in Ubuntu.
https://bugs.launchpad.net/bugs/1598810

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

Status in apt package in Ubuntu:
  New

Bug description:
  As per [0], `apt-get install python3.4` won't raise an error (despite
  the package not existing in xenial, and no installation happening),
  but `apt-get install not-a-real-package` will.  I would expect the
  behaviour to be the same in both cases.

  This may cause issues for users upgrading from trusty to xenial.  If
  someone is running a Python application that relies on Python 3.4,
  their automation may run "apt-get install python3.4" to ensure that
  Python 3.4 is available, expecting it to raise an error if python3.4
  does not end up installed.  It won't, and they will then unexpectedly
  be running 3.5.

  [0] http://paste.ubuntu.com/18443198/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1598810/+subscriptions