
On Mon, Aug 27, 2012 at 4:23 PM, Bryan O'Sullivan
On Mon, Aug 27, 2012 at 11:39 AM, Erik Hesselink
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 allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms