Bug#817832: apt-listbugs: Aborts complete upgrade instead of skipping package with bug

[Francesco Poli]

On Fri, 11 Mar 2016 23:02:15 +0100 Manuel Bilderbeek wrote:

[...]
> On 11-03-16 19:33, Francesco Poli wrote:
> >> But: how does pinning help? I don't want it to become permanently pinned.
> >
> > Each pin is automatically removed by a daily cron job, as soon as the
> > bug is fixed in the package version available for installation/upgrade.
> 
> Hmm, I used to pin something, but then it always was permanent. How does 
> the automatic unpinning work?

It checks whether the bug is fixed (or downgraded below the configured
severity threshold) in the version of the package that would get
installed without the pin itself. If this is the case, the pin is
actually removed and the installation/upgrade of the package becomes
possible again.

Please make sure that the cron daily job is run (if the system is up
and running almost 24/7, then cron should suffice, otherwise, the
installation of anacron is recommended).
Please also make sure that the Internet link is working while the cron
job is run.
Finally, you have to remember to keep the package indexes up-to-date
(with "apt update" or "aptitude update" or ...), in order for the
unpinning to work correctly.

[...]
> Just one suggestion: add 'p' to the hints at possible answers to the 
> question "Are you sure you want to install/upgrade the above packages?".
> Or simply behave as if 'p' was responded when people answer 'no', 
> because I would expect that to be the most likely answer that a 
> knowledgeable user would give.

"p" would pin all the listed buggy packages, which is not necessarily
what a user would always want to do (maybe one bug does not affect your
architecture or your use case, and you prefer to upgrade the package
despite the bug).

> Or change the question to something like: "What would you like to do 
> now? a) abort the upgrade b) pin these packages to their current 
> versions until the bugs are solved c) just continue the upgrade.

This is too long and detailed! It would be annoying for the users who
already know how to use the program.
On the other hand, the users who need to read explanations may always
use the on-line help (by answering '?'). 

[...]
> 
> Thanks for maintaining this useful package :)

You're welcome!;-)

Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpJ4nRH3YKBt.pgp
Description: PGP signature

Bug#817832: apt-listbugs: Aborts complete upgrade instead of skipping package with bug

[Manuel Bilderbeek]

Hi,

On 11-03-16 19:33, Francesco Poli wrote:

But: how does pinning help? I don't want it to become permanently pinned.


Each pin is automatically removed by a daily cron job, as soon as the
bug is fixed in the package version available for installation/upgrade.


Hmm, I used to pin something, but then it always was permanent. How does 
the automatic unpinning work?



And indeed you usually do not have to worry about pins.
As I said, please take a look at the documentation, whenever you have
doubts.


I just read it, thanks for reminding me again. And thanks for simply 
quoting the appropriate parts of the documentation to me :)


Just one suggestion: add 'p' to the hints at possible answers to the 
question "Are you sure you want to install/upgrade the above packages?".
Or simply behave as if 'p' was responded when people answer 'no', 
because I would expect that to be the most likely answer that a 
knowledgeable user would give.
Or change the question to something like: "What would you like to do 
now? a) abort the upgrade b) pin these packages to their current 
versions until the bugs are solved c) just continue the upgrade.


If any of these would be implemented, it would be more obvious to users 
this package what response to give.


Thanks for maintaining this useful package :)

--
Grtjs, Manuel

PS: MSX FOR EVER! (Questions? http://faq.msxnet.org/ )
PPS: Visit my homepage at http://manuel.msxnet.org/

Bug#817832: apt-listbugs: Aborts complete upgrade instead of skipping package with bug

[Francesco Poli]

On Fri, 11 Mar 2016 13:21:01 +0100 Manuel Bilderbeek wrote:

> Hi,
> 
> Thanks for your response.

You are welcome!

> 
> But: how does pinning help? I don't want it to become permanently pinned.

Each pin is automatically removed by a daily cron job, as soon as the
bug is fixed in the package version available for installation/upgrade.

> Only for the current action (dist-upgrade for instance) I want the package
> pinned... Suppose I do a dist-upgrade again a few days later, and the bug
> is fixed, then I want to include that package in the upgrade automatically,
> without worrying about pins.

And indeed you usually do not have to worry about pins.
As I said, please take a look at the documentation, whenever you have
doubts.

Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpu7PAoQD1hZ.pgp
Description: PGP signature

Bug#817832: apt-listbugs: Aborts complete upgrade instead of skipping package with bug

[Manuel Bilderbeek]

Hi,

Thanks for your response.

But: how does pinning help? I don't want it to become permanently pinned.
Only for the current action (dist-upgrade for instance) I want the package
pinned... Suppose I do a dist-upgrade again a few days later, and the bug
is fixed, then I want to include that package in the upgrade automatically,
without worrying about pins.

So I still think for the scenario where you indeed have critical bugs
listed which make you decide to skip the upgrade of the package, the
usability could be greatly improved.

2016-03-11 0:20 GMT+01:00 Francesco Poli :

> On Thu, 10 Mar 2016 19:22:36 +0100 Manuel Bilderbeek wrote:
>
> > Package: apt-listbugs
> > Version: 0.1.17
> > Severity: normal
> >
> > Dear Maintainer,
>
> Hello Manuel,
> thanks for using apt-listbugs!
>
> >
> > I thought the purpose of this package was to warn you that there is a
> critical
> > bug in a package you're upgrading, so you can skip upgrading that
> package.
>
> Indeed, it is.
>
> > But
> > when you say "No" to the question "Do you want to continue" (or whatever
> it
> > is), the whole upgrade is aborted.
>
> Please take a look at the documentation (man page, README.Debian), but,
> above all, use the on-line help: if you answer "n" to the "Are you sure
> you want to install/upgrade the above packages?", you are saying that
> you want to abort the installation/upgrade.
>
> If you answer "?", you will see the on-line help.
> Among other possible answers, there are:
>
>p  - pin pkgs (restart APT session to enable).
>p - pin all the above pkgs (restart APT session to enable).
>
> These commands will pin the packages that you fear would introduce
> troublesome bugs into your system (or all the buggy packages that
> apt-listbugs has just listed).
>
> > I would expected the package with the bug to
> > remain at the current version and the rest of the upgrade is just
> performed as
> > it should (as far as that's possible).
>
> The purpose of the package pinning is exactly to force the pinned
> packages to remain at their current state (at their currently installed
> version or at their current not-installed state).
>
> Unfortunately, after pins have been placed by apt-listbugs, your
> package manager of choice (apt, or aptitude, or ...) won't re-read its
> configuration files. As a consequence, after pinning some packages, you
> have to answer "n" in order to abort the installation/upgrade and then
> issue the package management command again (for instance "aptitude
> safe-upgrade"). At that point the pins will be effective.
>
> >
> > This makes the package a lot less usable as it could have been.
>
> I agree that it would great, if apt or aptitude could dynamically
> re-read their configuration and change behavior on the fly, but this is
> not the case, as far as I know.
>
> However, I am convinced that apt-listbugs is usable anyway.
> I am therefore closing your bug report.
>
> Thanks for getting in touch, though.
> Bye.
>
>
> --
>  http://www.inventati.org/frx/
>  There's not a second to spare! To the laboratory!
> . Francesco Poli .
>  GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE
>



-- 
Grtjs,

Manuel
PS: http://manuel.msxnet.org/

Bug#817832: apt-listbugs: Aborts complete upgrade instead of skipping package with bug

[Manuel Bilderbeek]

Package: apt-listbugs
Version: 0.1.17
Severity: normal

Dear Maintainer,

I thought the purpose of this package was to warn you that there is a critical
bug in a package you're upgrading, so you can skip upgrading that package. But
when you say "No" to the question "Do you want to continue" (or whatever it
is), the whole upgrade is aborted. I would expected the package with the bug to
remain at the current version and the rest of the upgrade is just performed as
it should (as far as that's possible).

This makes the package a lot less usable as it could have been.

-- System Information:
Debian Release: stretch/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.3.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages apt-listbugs depends on:
ii  apt 1.2.6
ii  ruby1:2.3.0+1
ii  ruby-debian 0.3.9+b5
ii  ruby-gettext3.1.7-1
ii  ruby-soap4r 2.0.5-3
ii  ruby-unicode0.4.4-2+b6
ii  ruby-xmlparser  0.7.3-1+b3
ii  ruby2.1 [ruby-interpreter]  2.1.5-4
ii  ruby2.2 [ruby-interpreter]  2.2.4-1
ii  ruby2.3 [ruby-interpreter]  2.3.0-4

Versions of packages apt-listbugs recommends:
ii  ruby-httpclient  2.7.1-1

Versions of packages apt-listbugs suggests:
ii  chromium [www-browser]   49.0.2623.75-2
ii  debianutils  4.7
ii  iceweasel [www-browser]  44.0.2-1
ii  reportbug6.6.6
ii  w3m [www-browser]0.5.3-27

-- no debconf information