[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#650132: marked as done (hint: binary to source mapping has unhelpful side-effects)

Your message dated Wed, 09 Dec 2015 20:38:58 +0000
with message-id <1449693538.5897.30.camel@adam-barratt.org.uk>
and subject line Re: Bug#650132: hint: binary to source mapping has unhelpful side-effects
has caused the Debian Bug report #650132,
regarding hint: binary to source mapping has unhelpful side-effects
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
650132: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650132
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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 ---
Reply to: