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 Touch seeded packages, 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 -- Mailing list: https://launchpad.net/~touch-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
