[Bug 1598810] Re: `apt-get install python3.4` on xenial exits 0 despite python3.4 not being available
David Kalnischkies
1598810 at bugs.launchpad.net
Mon Jul 4 15:15:50 UTC 2016
(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
--
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
More information about the foundations-bugs
mailing list