Bug#864681: Apt ux improvment: retry on lock aquisition

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#864681: Apt ux improvment: retry on lock aquisition

David Britton-2
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.


--
David Britton <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Bug#864681: Apt ux improvment: retry on lock aquisition

Julian Andres Klode-4
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.

--
Debian Developer - deb.li/jak | jak-linux.org - free software dev
                  |  Ubuntu Core Developer |
When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to ('inline').  Thank you.

Reply | Threaded
Open this post in threaded view
|

Bug#864681: Apt ux improvment: retry on lock aquisition

Julian Andres Klode-4
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