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

[James McCoy]

Control: clone -1 -2 -3
Control: retitle -2 Only non-suffixed version strings should be sent to other programs
Control: severity -2 normal
Control: retitle -3 Pinned package is upgraded due to strict Depends from another package
Control: severity -3 normal

On Fri, Oct 10, 2014 at 09:09:35PM +0300, Eugene V. Lyubimkin wrote:
> 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?

I ran "cupt safe-upgrade" and when apt-listbugs, run by cupt, showed me
the set of bugs that would be introduced by upgrading, I used its 'p'
option to pin the packages.

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

Cupt showing the suffixed versions isn't a problem.  The problem is that
cupt is sending those suffixed versions to other programs.  This should
be avoided, or at the very least avoided when running the dpkg hooks.
I've cloned this to another bug.

> > 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.
> 
> 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.

Hmm, so this might end up being a wishlist report on apt-listbugs to use
a "stronger" pin.

> > 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.

Done.