Re: lens build failures

On Sat, May 10, 2014 at 5:41 AM, Joachim Breitner <nomeata@debian.org> wrote:

Hi Edward,

looking at this issue again...

Am Montag, den 28.04.2014, 15:22 -0400 schrieb Edward Kmett:

> A better fix might be to push down the no-TH machinery to the
> reflection package and add back the dependency.
>
> The core of reflection should work fine without TH. It is just the
> splices for `int`, `nat` and the liftings of numeric instances that
> let you write `$(5)` to splice a type Nat that need to be disabled.
>
> Also, it might be worth considering if thereis a problem with building
> the actual template-haskell library on stage1 or merely with using the
> LANGUAGE pragma for TemplateHaskell on stage1.

I’m a bit confused by the situation. Unless I’m mistaken, then version
1.2.0.1 (which is in Debian) uses no TemplateHaskell at all.

1.3 starts using TH features that would not work on a stage1 compiler, I
believe. Do you have to use TH here or can do without?

template-haskell has to be used there because otherwise those instances are orphans in another package, which is not an acceptable packaging option to me as it breaks a ton of users. That said, if you don't have template-haskell on those platforms, those instances could never be used, but the rest of reflection is still usable.

> If it is just the latter I'd say you might consider including
> template-haskell, but hunting for the uses of the TemplateHaskell
> pragma instead.

We have the uses in (the new) reflection, so we either
* skip this package and all reverse dependencies, including lense,
on non-TH-arches
* skip this package and patch out its uses from its revdeps
* patch out the actual TH-using elements of reflection and hope
that they are not needed.

They are not needed to support the core usecase of reflection. They are needed however, to allow the user to use template-haskell splices to get constant natural numbers that are instances of Reifies. This is a 'niche'-like usecase, however, and doesn't affect 90% of the users of the library.

Users of libraries like rounded like to do things like pi :: Rounded TowardZero $(512) -- to support older GHC versions, but on newer GHCs pi :: Rounded TowardZero 512 also works, removing the pressure.

So the orphan instances of Num for Type and Exp and Foo a => Foo (Q a) are there mostly to support legacy GHCs.

If the decision for packaging in debian is that you want to not bring in the template-haskell package, then these could be excised from the debian version of the package with little damage to most users, especially as long as you are packaging a GHC >= 7.6.3.

The further down the less cut-down is the support on
on-TH-architectures, but also the more work it is and the risk of
unexpected breakage is higher.

What you are currently excising from lens causes a great deal more breakage than simpy excising those 3 instances from reflection for a package you don't support.

> At least fix-doctest-float-implementations.diff isn't needed any more.
> We merged something like it a while ago.

Thanks. We actually didn’t apply that patch (its not in the series
file), but it was just a left over.

Fair enough. I was just starting from the top.

Am Montag, den 28.04.2014, 16:04 -0300 schrieb Raúl Benencia:

> I didn't want to release the version 2 of the package because a test is
> failing on some[1] architectures due to rounding issues. Can anyone suggest
> a clean way, other than disabling the test, to fix this problem?
>
> [1] https://buildd.debian.org/status/package.php?p=haskell-lens

That’s just hurd, is it? In that case, ignore it. And also otherwise: An
upload does not have to fix all problems, it is always useful to have it
fix one problem.

The issue is fixed in HEAD as well. It was just a display issue between the two different floating point implementations. We just modified the test to avoid the problem, simply to make it a better, more robust, test.

-Edward

Greetings,
Joachim

--
Joachim "nomeata" Breitner
Debian Developer
nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata