[Pkg-puppet-devel] Bug#698294: Bug#698294: Bug#698294: diff for NMU 2.7.18-2.1

[micah anderson]

Russ Allbery <rra at debian.org> writes:

> Anton Gladky <gladk at debian.org> writes:
>
>> Ok, I canceled the upload.
>
>> We cannot postpone Wheezy-release, waiting for every upstream's
>> decision. If the solution works, why should not it be applied?
>> Otherwise the package should be removed from testing.

The solution may work, but if upstream deems the code insufficient it
might be because of some very important reasons. For example, it might
make this specific situation work, but breaks other things, or only
works for one case, but not another, or many other possible reasons. 

For this issue, what caused this upstream was a fix for another issue,
and I am not sure that the proposed fix will cause the original issue to
re-appear, I dont want a regression for that issue to come up as a
result.

I don't think it is such a great idea to stuff something into the Debian
package that upstream has a problem with, it tends to make upstream
unhappy when they have to deal with the fact that it exists in the
Debian package for years. In particular I'm thinking of how great they
have been when security issues have come up and they've produced
backports of fixes for the versions that we carry. If their backports
aren't going to work because we decided to put in some code that they
didn't like in the first place, how do we deal with the security fix
then?

> The problem is mildly obscure (many Puppet manifests, including very
> complex and non-trivial ones, will never trigger this error condition) and
> absolutely does not warrant removing the package from testing.  In fact,
> I'm tempted to downgrade it to important again, although if there is a
> tested upstream fix, I'd be in favor of applying it for wheezy.

I have to agree with Russ, this is a kind of weird corner case.

micah