--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: hint: binary to source mapping has unhelpful side-effects
- From: "Adam D. Barratt" <adam@adam-barratt.org.uk>
- Date: Sat, 26 Nov 2011 20:38:24 +0000
- Message-id: <1322339905.16684.24.camel@hathi.jungle.funky-badger.org>
Package: release.debian.org
User: release.debian.org@packages.debian.org
Usertags: tools
hint's automagic binary to source mapping has unintended and undesired
side-effects in some circumstances. The situation where issues have
been noticed most is with "hint clean" and renamed source packages, but
it will likely manifest in other cases.
By way of an example, assume that the source package "libfoo-ruby"
previously produced a binary of the same name. The binary package is
now produced by "ruby-foo", so a remove hint is added for the old source
package.
On the clean run after the libfoo-ruby source is removed, hint will read
the remove hint and attempt to update the versions. Noticing that there
is no libfoo-ruby source package in testing, it will try using a binary
package of that name and then successfully map it back to ruby-foo.
Rather than moving the remove hint below the "finished" marker, the end
result is instead that the hints file contains a remove hint for the
_new_ source package, ruby-foo.
I haven't found an easy way of resolving this yet, so am filing this in
the BTS so that the issue is documented and in case anyone else has any
thoughts.
Adam
--- End Message ---
--- Begin Message ---
On Wed, 2015-12-09 at 19:46 +0000, Adam D. Barratt wrote:
> On Wed, 2015-12-09 at 16:54 +0100, Julien Cristau wrote:
> > On Fri, Dec 4, 2015 at 19:09:47 +0000, Adam D. Barratt wrote:
> >
> > > diff --git a/scripts/hint b/scripts/hint
> > > index 9d38274..3b3b1ee 100755
> > > --- a/scripts/hint
> > > +++ b/scripts/hint
> > > @@ -513,9 +513,11 @@ class Hint(object):
> > >
> > > ##
> > >
> > > - def __init__(self, hintname, *args):
> > > + def __init__(self, hintname, *args, **kwargs):
> >
> > I'd prefer an explicit 'update' kwarg, defaulting to True. That'd not
> > give the impression that we're going to do anything with arbitrary
> > kwargs, be more self-documenting, and avoid a 'noupdate=False' confusing
> > double negation.
>
> As per our IRC conversation, Python 2 doesn't make that particularly
> easy to accomplish, so I've ported hint to Python 3, thus allowing
> explicitly named arguments to occur after the varargs parameters.
>
> I've attached a revised patch on that basis, which feels a lot cleaner
> (at least IMO).
I've committed and deployed that patch, so I believe this is now
resolved.
Regards,
Adam
--- End Message ---