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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1598810 Title: `apt-get install python3.4` on xenial exits 0 despite python3.4 not being available To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1598810/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
