Re: hamcrest 1.2
Thanks for the reply Damien,
I just have a general aversion to epochs as they are a permanent
solution to a temporary problem, but if the consensus is that an epoch
is preferred over two binary packages from the same source package,
I'm happy to do it. In fact, if no one else weighs in, I'll proceed
with this tomorrow and also upload the libhamcrest1.2-java package
that is already in Ubuntu.
Regards,
Brian
On Mon, Mar 12, 2012 at 6:25 PM, Damien Raude-Morvan
<drazzib@drazzib.com> wrote:
> On 12/03/2012 22:04, Brian Thomason wrote:
>>
>> Hello all,
>
>
> Hi Brian,
>
>
>> I uploaded hamcrest 1.2 some time ago in efforts to get the dependency
>> chain of Eucalyptus 3.1 in place which we plan to upload to Debian
>> soon. I was unaware that junit4 still fails to build against anything
>> greater than 1.1 - sorry about that!
>>
>> In Ubuntu, I solved the problem by simply creating a
>> libhamcrest1.2-java package, but it is obviously too late (sans an
>> epoch, which I try to avoid like the plague) to do the same for Debian
>> as 1.2 is already in unstable. I was thinking I should package both
>> 1.1 and 1.2 in the 1.2 package and have 1.1 as the default to solve
>> the problem. Is this an acceptable solution?
>
>
> Some days ago, I've managed to create a workaround in Debian by using some
> hack [1] to force "unchecked" cast from junit matchers to hamcrest one. FTR,
> JUnit test suite work with those changes and there is no-API change.
>
> There is some work (upstream) to allow JUnit to work cleanly with hamcrest
> 1.2 [2] but there is yet no solution.
>
> So, in the mean time, we need to provide both 1.2 and 1.1 hamcrest. I'm not
> found of providing both binary packages from a same source. What's wrong for
> you with epoch ? It seems to be a good solution to this...
>
> [1]
> http://patch-tracker.debian.org/patch/series/view/junit4/4.10-1/workaround_typing_bug.diff
> [2] https://github.com/KentBeck/junit/issues/36
> --
> Damien
Reply to: