Bug#864681: Apt ux improvment: retry on lock aquisition
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
Reply to: