[Cupt-devel] Bug#764238: Bug#764238: libcupt3-0: Version selectors are exposed to external tools, breaking pinning

[Eugene V. Lyubimkin]

Control: retitle -1 non-suffixed version strings in preferences aren't matched properly

Hi James,

s/version selectors/version string id suffixes [1]/

Thank you for your report! There are several things here:

2014-10-06 11:08, James McCoy:
> Doing an update today, apt-listbugs showed a bugs that seemed worth
> pinning the packages over, so I did that.  This resulted in
> /etc/apt/preferences.d/apt-listbug containing pins like
> 
>   Pin: version 1.17.13^installed
> 
> Any tool other than cupt doesn't understand that version, which means
> that e.g. a pinned package related to a security upgrade may get
> upgraded when it shouldn't (unattended-upgrades).

Any tool which parses cupt's output is supposed to understand its way of
saying things. For many commands cupt does mimic the apt way of saying
things just for the sake of users/tools who wants to parse both with
minimal effort, but for some commands it's intended to be different.

I didn't know apt-listbugs started to parse cupt's output. Or was it
put by you or another tool?

If you still think that showing id suffixes is a bug, please clone this
bug and let's continue discussion there.

[1] https://people.debian.org/~jackyf/cupt2/tutorial.html#id_suffixes


> Removing the version selector from the pin causes apt to understand the
> pin again, but now cupt doesn't:
> [...]

No questions here, this is a regression, many thanks for noticing, will
be fixed in the next patch release.


> Regardless of how the pin is specified, cupt still decides to upgrade
> dpkg-dev due to libdpkg-perl having a lock-step Depends on dpkg-dev,
> although at different scores.
[...]
> Without the version selector:
> D: (0:0) problem (3:1): <user requests> <not installed>: custom: upgrade libdpkg-perl
> D: (0:0) -> (1,Δ:[uw=-460]) trying: '' -> 'unsatisfied custom: upgrade libdpkg-perl'
> D: (0:0) -> (2,Δ:[401v/u/pp=539]) trying: 'libdpkg-perl 1.17.13^installed' -> 'libdpkg-perl 1.17.15'
> D: (0:0) -> (3,Δ:[-200v/r/ra/2pp=-764]) trying: 'libdpkg-perl 1.17.13^installed' -> 'libdpkg-perl <not installed>'
> D:  (2:539) problem (5:2): dpkg-dev 1.17.13^installed: depends 'libdpkg-perl (= 1.17.13)'
> D: ignoring soft dependency relation: dpkg-dev 1.17.15: recommends 'libalgorithm-merge-perl'
> D:  (2:539) -> (4,Δ:[-200v/r=-1960]) trying: 'dpkg-dev 1.17.13^installed' -> 'dpkg-dev <not installed>'
> D:  (2:539) -> (5,Δ:[401v/u/pp=539]) trying: 'dpkg-dev 1.17.13^installed' -> 'dpkg-dev 1.17.15'

This is the most interesting part.

First, indeed, there is a deficiency here that new libdpkg-perl gets too
high score. This is partly fixed in master already, and, hopefully, will
get even better in 2.9.0.

Second, even with the issue above fixed, dpkg-dev will still likely get
upgraded if you issue an usual upgrade command. Pin of 1000, for Cupt,
says that you only slightly prefer that version over others. Sure, it
would get selected if there are no problems but doesn't quite stand the
competition versus user-wanted upgrade. Even worse if there are several
upgradable packages with doesn't like kept version.

At least right now, the stronger the version needs to be "kept", more
zeroes should be added to the pin. Something like 100000 for this
case.

> I can split this part out to a separate bug if you'd like.

Yes, please. There we can discuss what can be done if anything.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer