Quantcast

Cabal install fails due to recent HUnit

classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cabal install fails due to recent HUnit

Ross Paterson
On Mon, Aug 27, 2012 at 07:39:39PM +0100, Erik Hesselink wrote:
> If we do agree that we want to prevent this problem for a while (which
> I'm not sure about), we should probably do it by preventing uploads
> for packages like this. That way, package maintainers will know what
> is going on, just like with the other 'package quality' issues hackage
> enforces.

The place to check is Distribution.PackageDescription.Check.checkPackage
(in Cabal).  If this returns anything other than PackageDistSuspicious,
hackage will reject the upload.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cabal install fails due to recent HUnit

Ross Paterson
In reply to this post by Brent Yorgey-2
On Mon, Aug 27, 2012 at 09:03:18PM +0100, Brent Yorgey wrote:

> On Mon, Aug 27, 2012 at 10:52:59AM -0700, Bryan O'Sullivan wrote:
> > On Mon, Aug 27, 2012 at 9:57 AM, Erik Hesselink <[hidden email]> wrote:
> >
> > > I'm seeing this again, on abstract-deque-0.1.6. Ross, can you fix it again?
> > >
> >
> > Hang on a second.
> >
> > The reason you're seeing build breakage is that the .cabal files of the
> > broken packages were edited in-place without communicating with any of the
> > package authors.
> >
> > I understand that the collective intentions around this were good, but by
> > "fixing" things without telling anyone, package maintainers have no way to
> > know that anything has happened. Now we are seeing the problem begin to
> > recur as people issue new releases that don't incorporate those changes.
>
> For the record, abstract-deque was neither one of the packages fixed
> previously, nor does its .cabal file even contain a test section at
> all, much less one with a conditional.

It did a couple of hours ago.

> But I
> agree with Bryan in principle that we need a more principled approach.

Yes, and Cabal is the place to test for this.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cabal install fails due to recent HUnit

Bryan O'Sullivan
In reply to this post by Erik Hesselink
On Mon, Aug 27, 2012 at 11:39 AM, Erik Hesselink <[hidden email]> wrote:

Yes, you are right. So the question is how long to support systems
with the old cabal 0.10. This is the one included with the previous
haskell platform (and thus lots of linux distro's), which is less than
a year old. But it's also pretty old, since there weren't any cabal
releases for a while.

That's a very awkward situation. At least in the future, Johan and I have a proposal to make this class of problem more avoidable by introducing a regular release schedule. See the thread that starts here for details: http://www.haskell.org/pipermail/cabal-devel/2012-August/008987.html

For the state of things today, it's not obvious to me what to do.

It's burdensome to ask package authors to remove stuff from their packages because it can't be handled by a broken version of cabal, especially since there's no upper bound on how long that broken version will be floating around. We'd essentially be giving up on this feature semi-permanently, which would make me sad because it's so useful.

Just as unappealing is the idea of breaking builds for people who, through no fault of their own, are using the broken cabal. However, at least this class of people has the incentives aligned to do something about their problem: either upgrade cabal-install or their distro.

The other question is how useful test suites in a released package
are. Aren't they much more useful (and used more often) in source
repositories?

They're certainly useful in source repositories, and we have historically chosen not to make a distinction between what's in a source repo and what gets shipped to end users via cabal, which makes sense to me.

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cabal install fails due to recent HUnit

Brandon Allbery
On Mon, Aug 27, 2012 at 4:23 PM, Bryan O'Sullivan <[hidden email]> wrote:
On Mon, Aug 27, 2012 at 11:39 AM, Erik Hesselink <[hidden email]> wrote:

Yes, you are right. So the question is how long to support systems
with the old cabal 0.10. This is the one included with the previous
haskell platform (and thus lots of linux distro's), which is less than
a year old. But it's also pretty old, since there weren't any cabal
releases for a while.

That's a very awkward situation. At least in the future, Johan and I have a proposal to make this class of problem more avoidable by introducing a regular release schedule. See the thread that starts here for details: http://www.haskell.org/pipermail/cabal-devel/2012-August/008987.html

While it's a bit late now, a regular extension syntax of some kind might help.  Something that unavoidably breaks an actual install should throw an error, other stuff should issue a warning (or even be ignored if not part of the main sequence; these packages that  are causing breakage currently are doing so via index entries, I think, not by the packages themselves being built?).

One trick you see in some environments, for example, is that X-$thing is ignored by older versions that don't know about $thing, and treated as $thing by those that do.  If something needs $thing to build, then it will throw the error about $thing, but it won't break just by having X-$thing present.  Eventually you can remove the "X-" prefix.

(The difference between this and just ignoring unknowns is you don't completely lose protection from typoes and such.  The "X-" could be understood as downgrading an error to a warning in some circumstances.)

Another possibility, possibly used along with the above, is some kind of syntax update that is shipped along with "cabal update".  It would not enable cabal to *use* a new feature but could prime it to be *parsed* and not throw unnecessary errors.

--
brandon s allbery                                      [hidden email]
wandering unix systems administrator (available)     (412) 475-9364 vm/sms


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cabal install fails due to recent HUnit

Ryan Newton
In reply to this post by Brent Yorgey-2
Well, this one looks like it was my fault because I never read this thread and this morning I uploaded that package (abstract-deque) with the conditional in the test-suite.  The reason this conditional isn't there now is that the package was hacked in place to remove tests, which is fine.

Actually, as a maintainer I'm not really clear on how to test this behavior.  I tried "cabal configure" with cabal-install-0.10.2 as in the original post and I couldn't reproduce the problem.

 
For the record, abstract-deque was neither one of the packages fixed
previously, nor does its .cabal file even contain a test section at
all, much less one with a conditional.  So if cabal-install-0.10 is
failing to read it, it is because of some different problem.  But I
agree with Bryan in principle that we need a more principled approach.

-Brent

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cabal install fails due to recent HUnit

Tristan Seligmann-3
In reply to this post by Erik Hesselink

On Aug 27, 2012 8:40 PM, "Erik Hesselink" <[hidden email]> wrote:
>
> The other question is how useful test suites in a released package
> are. Aren't they much more useful (and used more often) in source
> repositories?

Having tests available in a released package allows one to verify that the software is functional in its current configuration / state on your system; this seems extremely useful to me.


_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cabal install fails due to recent HUnit

wren ng thornton
On 8/27/12 6:27 PM, Tristan Seligmann wrote:
> On Aug 27, 2012 8:40 PM, "Erik Hesselink" <[hidden email]> wrote:
>>
>> The other question is how useful test suites in a released package
>> are. Aren't they much more useful (and used more often) in source
>> repositories?
>
> Having tests available in a released package allows one to verify that the
> software is functional in its current configuration / state on your system;
> this seems extremely useful to me.

indeed.

--
Live well,
~wren

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cabal install fails due to recent HUnit

Bryan O'Sullivan
In reply to this post by Bryan O'Sullivan
On Mon, Aug 27, 2012 at 10:52 AM, Bryan O'Sullivan <[hidden email]> wrote:
The reason you're seeing build breakage is that the .cabal files of the broken packages were edited in-place without communicating with any of the package authors.

Not to flog a dead horse, but:

Just yesterday we had a communication from someone on the Gentoo Linux packaging team that their checksum validation for the bloomfilter package was failing. This problem arose because of the hand-editing of the package, but confusion arose in the bug report due to misattribution of the source of the error.


Hand-editing uploaded tarballs: just don't do it, kids!

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cabal install fails due to recent HUnit

Erik Hesselink
On Tue, Aug 28, 2012 at 6:09 PM, Bryan O'Sullivan <[hidden email]> wrote:

> On Mon, Aug 27, 2012 at 10:52 AM, Bryan O'Sullivan <[hidden email]>
> wrote:
>>
>> The reason you're seeing build breakage is that the .cabal files of the
>> broken packages were edited in-place without communicating with any of the
>> package authors.
>
> Not to flog a dead horse, but:
>
> Just yesterday we had a communication from someone on the Gentoo Linux
> packaging team that their checksum validation for the bloomfilter package
> was failing. This problem arose because of the hand-editing of the package,
> but confusion arose in the bug report due to misattribution of the source of
> the error.
>
> https://github.com/haskell/cabal/issues/1017
>
> Hand-editing uploaded tarballs: just don't do it, kids!

Not to flog a dead horse, but:

All our builds broke again yesterday due to this bug. The package was
iteratee-0.8.9.3, though given the vocal opposition of Bryan
O'Sullivan, I won't advocate fixing it in place just now.

I've built the test in the Cabal library to reject packages with
conditionals in the test-suites section. I'm just not sure if we want
to implement this on hackage, and for how long.

I'm not quite sure how old this cabal version is that is causing the
problems, but the haskell platform it comes with is 2011.2, which
means the second quarter of 2011, so that is a little over a year old.
It comes with Ubuntu 11.10, which is less than a year old.

I was going to argue to support versions of cabal (and GHC) for at
least a year. That means that if you're on Ubuntu, which has releases
every 6 months, you have 6 months to upgrade. However, that year has
already expired for cabal 0.10, or is about to expire if you count the
Ubuntu release it came with.

So what do others think? Does the haskell community want to support
anything other than the bleeding edge? If so, for how long?

Regards,

Erik

_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Cabal install fails due to recent HUnit

Chris Dornan
>On Tue, Aug 28, 2012 at 6:09 PM, Bryan O'Sullivan <[hidden email]>
wrote:
>> On Mon, Aug 27, 2012 at 10:52 AM, Bryan O'Sullivan
>> <[hidden email]>
>> wrote:
>>
>> Not to flog a dead horse, but:
>>
...
>Not to flog a dead horse, but:
>
>All our builds broke again yesterday due to this bug. The package was
iteratee-0.8.9.3, though given the vocal opposition of Bryan O'Sullivan, I
won't advocate fixing it in place just now.
...
>I was going to argue to support versions of cabal (and GHC) for at least a
year. That means that if you're on Ubuntu, which has releases every 6
months, you have 6 months to upgrade. However, that year has already expired
for cabal 0.10, or is about to expire if you count the Ubuntu release it
came with.
>
>So what do others think? Does the haskell community want to support
anything other than the bleeding edge? If so, for how long?

While we are all making glue, it really, really doesn't need to be like
this! (Everybody is going to hate me for this and I am quite sure I am going
to be ignored, but my conscience forbids me from staying quiet.)

Every one of my Haskell Platform releases on justhub.org provides all the
libraries and tools needed for
that platform, which gets laid on top of the existing platforms (which can
be removed when they are no longer needed).

Each project can chooses its platform, and can pin whatever packages it
needs to use without fear of being disrupted,
while installing new GHC and platform releases for use with other projects.
(Proper package erasure is supported too.)

With trivial effort source trees can be moved around among different systems
and rebuilt in the exact same configuration.

The standard tools (ghc, ghci, ghc-pkg, cabal, etc.) can be used just as
normal. All the developer needs to do is designate which platform
(or bare ghc) to be used at the root of each work tree -- or leave it to use
the platform-du-jour.

I can only describe working with this kind of environment as peaceful
(certainly not cabal hell).

Trying to mutate and maintain coherent an ever-growing network of packages
is not a scalable way of doing business. If on top
of this the history gets  patched up aren't things going to get even more
confusing?

I know that this way of doing things won't provide immediate relief (it's
too radical relative to where everybody is) but I am
trying to address Erik's question about what we should be aiming for.
Shouldn't we be trying to find a sustainable, long-term,
preferred method of delivering stable Haskell development environments? Why
not a functional model? What is not to like?

I will be at the CUFP if anybody would like to see a live demo or debate any
of these points.

Chris



_______________________________________________
Haskell-Cafe mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/haskell-cafe
12
Loading...