Version: 1.9.11 On Tue, Jun 13, 2017 at 10:59:46PM +0200, Julian Andres Klode wrote: > Control: tag -1 confirmed > > On Mon, Jun 12, 2017 at 02:01:01PM -0600, David Britton wrote: > > Package: apt > > Version: 1.4.6 > > > > > > In working on: https://bugs.launchpad.net/cloud-init/+bug/1693361, as > > well as many other pieces of software throughout my time working with > > Ubuntu, the lack of a retry on lock acquisition is certainly an area > > where apt and libapt could improve. > > > > As it stands, all client applications that interact with Apt are > > burdened with similar boilerplate concepts of blind retries with backoff > > algorithms. > > > > A single command line with more advanced config settings would probably > > satisfy the bulk of use cases. > > > > apt --retry-lock-timeout 30 > > > > With NEVER being the default (forever), and duration to retry in minutes as > > the accepted parameter, 0 meaning, don't retry, or timeout immediately. > > I have indeed been thinking about waiting for locks.
Since 1.9.11, apt(8) now waits for dpkg locks by default, apt-get(8) needs to be passed -o dpkg::lock::timeout=$seconds, where $seconds is either the seconds to wait or -1 to wait indefinitely. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
