From sm at khjk.org Thu Feb 1 06:57:01 2007 From: sm at khjk.org (Sven Moritz Hallberg) Date: Thu Feb 1 06:54:10 2007 Subject: Dependencies/backwards compatibility in Hackage Message-ID: <20070201115701.GA9097@panik.pesco.prv> Hi everyone, While trying out cabal-install today, I stumbled across the following: I wanted to install XmlRpc which depends on HaXml and works with HaXml-1.13.2. However, HaXml-1.17 which has also been uploaded to hackageDB changed an exposed module's name and XmlRpc doesn't work with it anymore. I'm wondering how to avoid such situations. I appears to me that expecting the maintainer of every package depending on HaXml to update their dependencies "after the fact" doesn't make sense because it leaves an arbitrarily long window where the package won't build straight out of hackageDB. Wouldn't it be sensible for the author of HaXml to specify in the .cabal file for version 1.17 whether it is backwards-compatible or not? I'd imagine a field like "compatible:" or something to name any older versions that this version is backwards-compatible to, e.g. name: base version: 2.0 compatible: 1.0 ... The field would default to "not backwards-compatible to anything" so it would fail safe in the case where it's not given. There would still be the possibility of the maintainer erroneously stating compatibility where there is none. For example, she could set the field at some point and forget to update it. There might be a clever way to avoid this pitfall, though. What's the general opinion, should something like the above be added? (I'd be willing to volunteer for the code work.) On a side note, it probably wouldn't be too hard with existing tools to build a "gatekeeper" program to detect obvious kinds of flux in the API when uploading a new package to hackageDB: Check that all old modules are there, export all old functions, and maybe whether all the old functions still have the same type signatures (otherwise warn and ask for confirmation...), etc. Regards, Sven Moritz From ross at soi.city.ac.uk Thu Feb 1 07:14:45 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Feb 1 07:09:43 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <20070201115701.GA9097@panik.pesco.prv> References: <20070201115701.GA9097@panik.pesco.prv> Message-ID: <20070201121445.GA9034@soi.city.ac.uk> On Thu, Feb 01, 2007 at 12:57:01PM +0100, Sven Moritz Hallberg wrote: > While trying out cabal-install today, I stumbled across the following: > I wanted to install XmlRpc which depends on HaXml and works with > HaXml-1.13.2. However, HaXml-1.17 which has also been uploaded to > hackageDB changed an exposed module's name and XmlRpc doesn't work with > it anymore. > > I'm wondering how to avoid such situations. I appears to me that > expecting the maintainer of every package depending on HaXml to update > their dependencies "after the fact" doesn't make sense because it leaves > an arbitrarily long window where the package won't build straight out > of hackageDB. We could decide on a standard interpretation of version numbers, e.g. major.minor.patch. To support this, we'd want wildcards like 1.13.* in version ranges. In the meantime, I'll remove HaXml-1.17 from HackageDB. From bringert at cs.chalmers.se Thu Feb 1 09:36:00 2007 From: bringert at cs.chalmers.se (=?ISO-8859-1?Q?Bj=F6rn_Bringert?=) Date: Thu Feb 1 09:30:54 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <20070201121445.GA9034@soi.city.ac.uk> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> Message-ID: <45C1FAD0.9080900@cs.chalmers.se> Ross Paterson wrote: > On Thu, Feb 01, 2007 at 12:57:01PM +0100, Sven Moritz Hallberg wrote: >> While trying out cabal-install today, I stumbled across the following: >> I wanted to install XmlRpc which depends on HaXml and works with >> HaXml-1.13.2. However, HaXml-1.17 which has also been uploaded to >> hackageDB changed an exposed module's name and XmlRpc doesn't work with >> it anymore. >> >> I'm wondering how to avoid such situations. I appears to me that >> expecting the maintainer of every package depending on HaXml to update >> their dependencies "after the fact" doesn't make sense because it leaves >> an arbitrarily long window where the package won't build straight out >> of hackageDB. > > We could decide on a standard interpretation of version numbers, e.g. > major.minor.patch. To support this, we'd want wildcards like 1.13.* > in version ranges. > > In the meantime, I'll remove HaXml-1.17 from HackageDB. I think that the correct solution to this problem would be to make a new release of haxr (which used to be XmlRpc) that works with HaXml 1.17. On a side note, I think that XmlRpc should be removed, or there should be a way for one package to obsolete another. The XmlRpc package has been renamed to haxr, to have a more uniform naming within the package. /Bj?rn From ross at soi.city.ac.uk Thu Feb 1 09:58:25 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Feb 1 09:53:49 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <45C1FAD0.9080900@cs.chalmers.se> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> Message-ID: <20070201145825.GB9034@soi.city.ac.uk> On Thu, Feb 01, 2007 at 03:36:00PM +0100, Bj?rn Bringert wrote: > I think that the correct solution to this problem would be to make a > new release of haxr (which used to be XmlRpc) that works with HaXml 1.17. rss also uses HaXml. I'm not sure if Malcolm intends HaXml 1.17 to be released yet. > On a side note, I think that XmlRpc should be removed, or there should > be a way for one package to obsolete another. The XmlRpc package has > been renamed to haxr, to have a more uniform naming within the > package. It is gone. From fawzi at gmx.ch Thu Feb 1 10:29:31 2007 From: fawzi at gmx.ch (Fawzi Mohamed) Date: Thu Feb 1 10:24:21 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <20070201121445.GA9034@soi.city.ac.uk> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> Message-ID: <45C2075B.2070508@gmx.ch> Ross Paterson wrote: > We could decide on a standard interpretation of version numbers, e.g. > major.minor.patch. To support this, we'd want wildcards like 1.13.* > in version ranges. [...] > Yes, I think a solution like this (major: distruptive change, minor: backward compatible change, patch: no api change) would be very nice. Then one would be able to have many different incompatible versions encoding the major version name into the path of the library (or library name). OSX Frameworks for example use this solution (with a symlink to the latest version that is used for normal builds, and last used major version for build objects). Fawzi From sm at khjk.org Thu Feb 1 10:41:53 2007 From: sm at khjk.org (Sven Moritz Hallberg) Date: Thu Feb 1 10:39:01 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <45C1FAD0.9080900@cs.chalmers.se> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> Message-ID: <20070201154153.GC15706@panik.pesco.prv> Bj?rn Bringert , 2007-02-01 15.36 +0100: > Ross Paterson wrote: > I think that the correct solution to this problem would be to make a new > release of haxr (which used to be XmlRpc) that works with HaXml 1.17. But then what is your answer to the problem of things breaking in the time between the release of HaXml 1.17 and making a new release of haxr? -Sven From sm at khjk.org Thu Feb 1 10:43:11 2007 From: sm at khjk.org (Sven Moritz Hallberg) Date: Thu Feb 1 10:40:19 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <20070201121445.GA9034@soi.city.ac.uk> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> Message-ID: <20070201154311.GD15706@panik.pesco.prv> Ross Paterson , 2007-02-01 12.14 +0000: > We could decide on a standard interpretation of version numbers, e.g. > major.minor.patch. To support this, we'd want wildcards like 1.13.* > in version ranges. Sounds compelling, but will everyone want/agree to follow that scheme? -Sven From bringert at cs.chalmers.se Thu Feb 1 10:49:26 2007 From: bringert at cs.chalmers.se (=?ISO-8859-1?Q?Bj=F6rn_Bringert?=) Date: Thu Feb 1 10:44:19 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <20070201154108.GB15706@panik.pesco.prv> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> Message-ID: <45C20C06.3060300@cs.chalmers.se> Sven Moritz Hallberg wrote: > Bj?rn Bringert , 2007-02-01 15.36 +0100: >> Ross Paterson wrote: >> I think that the correct solution to this problem would be to make a new >> release of haxr (which used to be XmlRpc) that works with HaXml 1.17. > > But then what is your answer to the problem of things breaking in the > time between the release of HaXml 1.17 and making a new release of haxr? > > -Sven I don't really have one, expect fast development :-). One possibility would be to have a convention about version number changes when libraries make backwards-incompatible API changes. E.g. HaXml should change major version whenever a change would break something that depends on it. Then all libraries which depend on HaXml could specify: Build-depends: HaXml >= 1.13 && < 2 or something like that. The only problem would be that it would be overly restrictive if a HaXml 2.0 comes out that the current version of the depending library actually works with. /Bj?rn From bringert at cs.chalmers.se Thu Feb 1 10:51:21 2007 From: bringert at cs.chalmers.se (=?ISO-8859-1?Q?Bj=F6rn_Bringert?=) Date: Thu Feb 1 10:46:14 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <45C20C06.3060300@cs.chalmers.se> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> <45C20C06.3060300@cs.chalmers.se> Message-ID: <45C20C79.3090402@cs.chalmers.se> Bj?rn Bringert wrote: > Sven Moritz Hallberg wrote: >> Bj?rn Bringert , 2007-02-01 15.36 +0100: >>> Ross Paterson wrote: >>> I think that the correct solution to this problem would be to make a >>> new release of haxr (which used to be XmlRpc) that works with HaXml >>> 1.17. >> >> But then what is your answer to the problem of things breaking in the >> time between the release of HaXml 1.17 and making a new release of haxr? >> >> -Sven > > I don't really have one, expect fast development :-). > > One possibility would be to have a convention about version number > changes when libraries make backwards-incompatible API changes. E.g. > HaXml should change major version whenever a change would break > something that depends on it. Then all libraries which depend on HaXml > could specify: > > Build-depends: HaXml >= 1.13 && < 2 > > or something like that. The only problem would be that it would be > overly restrictive if a HaXml 2.0 comes out that the current version of > the depending library actually works with. Eh that is what Ross already said. Sorry about that. This is the approach taken by Unix shared libraries by the way. /Bj?rn From ndmitchell at gmail.com Thu Feb 1 10:59:54 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Feb 1 10:54:46 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <45C20C79.3090402@cs.chalmers.se> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> <45C20C06.3060300@cs.chalmers.se> <45C20C79.3090402@cs.chalmers.se> Message-ID: <404396ef0702010759x775876e7u9dfe3e0e8fab45b3@mail.gmail.com> Hi We're all assuming here that HaXml deliberately decided to change the interface. Is that really true? (only Malcolm can answer) Most of the time I guess that the interface will change by accident, without people spotting. Perhaps we are trying to solve the wrong problem... Thanks Neil On 2/1/07, Bj?rn Bringert wrote: > Bj?rn Bringert wrote: > > Sven Moritz Hallberg wrote: > >> Bj?rn Bringert , 2007-02-01 15.36 +0100: > >>> Ross Paterson wrote: > >>> I think that the correct solution to this problem would be to make a > >>> new release of haxr (which used to be XmlRpc) that works with HaXml > >>> 1.17. > >> > >> But then what is your answer to the problem of things breaking in the > >> time between the release of HaXml 1.17 and making a new release of haxr? > >> > >> -Sven > > > > I don't really have one, expect fast development :-). > > > > One possibility would be to have a convention about version number > > changes when libraries make backwards-incompatible API changes. E.g. > > HaXml should change major version whenever a change would break > > something that depends on it. Then all libraries which depend on HaXml > > could specify: > > > > Build-depends: HaXml >= 1.13 && < 2 > > > > or something like that. The only problem would be that it would be > > overly restrictive if a HaXml 2.0 comes out that the current version of > > the depending library actually works with. > > Eh that is what Ross already said. Sorry about that. This is the > approach taken by Unix shared libraries by the way. > > /Bj?rn > _______________________________________________ > cabal-devel mailing list > cabal-devel@haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > From bos at serpentine.com Thu Feb 1 11:15:25 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Thu Feb 1 11:10:20 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <404396ef0702010759x775876e7u9dfe3e0e8fab45b3@mail.gmail.com> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> <45C20C06.3060300@cs.chalmers.se> <45C20C79.3090402@cs.chalmers.se> <404396ef0702010759x775876e7u9dfe3e0e8fab45b3@mail.gmail.com> Message-ID: <45C2121D.7000400@serpentine.com> Neil Mitchell wrote: > We're all assuming here that HaXml deliberately decided to change the > interface. Is that really true? (only Malcolm can answer) Yes, it's true. Even a non-Malcolm such as myself can answer this, because of the magnitude of the changes from 1.13 to 1.17. HaXml is somewhere in the process of a big spring cleaning. The real question that only Malcolm can answer is how far through the process of tidying up it is. That bears on whether it's worth bringing haxr up to date; if there's more churn ahead, the answer is probably "not yet". References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> <45C20C06.3060300@cs.chalmers.se> <45C20C79.3090402@cs.chalmers.se> <404396ef0702010759x775876e7u9dfe3e0e8fab45b3@mail.gmail.com> <45C2121D.7000400@serpentine.com> Message-ID: <45C212E6.7010807@cs.chalmers.se> Bryan O'Sullivan wrote: > Neil Mitchell wrote: > >> We're all assuming here that HaXml deliberately decided to change the >> interface. Is that really true? (only Malcolm can answer) > > Yes, it's true. Even a non-Malcolm such as myself can answer this, > because of the magnitude of the changes from 1.13 to 1.17. HaXml is > somewhere in the process of a big spring cleaning. > > The real question that only Malcolm can answer is how far through the > process of tidying up it is. That bears on whether it's worth bringing > haxr up to date; if there's more churn ahead, the answer is probably > "not yet". If an experimental HaXml version was added to Hackage, it should be tagged as such in some way. A cheapo way to do that is to call the package "HaXml-experimental" or some such. /Bj?rn From sm at khjk.org Thu Feb 1 11:29:44 2007 From: sm at khjk.org (Sven Moritz Hallberg) Date: Thu Feb 1 11:26:51 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <45C20C06.3060300@cs.chalmers.se> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> <45C20C06.3060300@cs.chalmers.se> Message-ID: <20070201162944.GB20332@panik.pesco.prv> Bj?rn Bringert , 2007-02-01 16.49 +0100: > >But then what is your answer to the problem of things breaking in the > >time between the release of HaXml 1.17 and making a new release of haxr? > > > >-Sven > > I don't really have one, expect fast development :-). Okay, but that's unreliable. The way I see it, the upshot of it would be that cabal-install would only actually work half the time. No fun! > One possibility would be to have a convention about version number > changes when libraries make backwards-incompatible API changes. E.g. > HaXml should change major version whenever a change would break > something that depends on it. Then all libraries which depend on HaXml > could specify: > > Build-depends: HaXml >= 1.13 && < 2 > > or something like that. The only problem would be that it would be > overly restrictive if a HaXml 2.0 comes out that the current version of > the depending library actually works with. What's wrong with the solution I proposed, i.e. to add an explicit field to the package description which states whether we broke compatibility or not? It's effectively the same as a version numbering convention without having to tell everyone how to assign their numbers. Don't get me wrong, I'd be all for a consistent numbering scheme. Is everyone else also? In the end, I just want two things: - As a library author I want to be able to freely change my interface around without having to fear tons of programs breaking. Of course interface stability is good, but not everyone has an Architecture Review Board behind them that makes sure the interface actually makes sense. If I discover that it doesn't, I want to be able to change it, not stagnate on the old crud because of backwards-compatibility. - As a user, I just want cabal-install to work reliably. That can only happen if incompatibility is somehow avoided. Let's note that one solution lingering around is the Debian-like stable/testing/unstable model, i.e. every new package would go into unstable, break possibly tons of stuff there, which possibly tons of people will have to fix up, taking considerable time. Some things might not get fixed at all -> old programs become unusable. After some time things would propagate to testing, hopefully not breaking too much, and finally appear in stable in all their glory. The (IMHO) undesirable consequence of this would be, however, that you would get the Debian-like tradeoff between stability and having access to the latest developments. With the ability to declare your incompatibility, ideally combined with some automatic checks, unstable could be removed. We might still want to have testing because you never know, though. -Sven From sm at khjk.org Thu Feb 1 11:30:27 2007 From: sm at khjk.org (Sven Moritz Hallberg) Date: Thu Feb 1 11:27:34 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <404396ef0702010759x775876e7u9dfe3e0e8fab45b3@mail.gmail.com> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> <45C20C06.3060300@cs.chalmers.se> <45C20C79.3090402@cs.chalmers.se> <404396ef0702010759x775876e7u9dfe3e0e8fab45b3@mail.gmail.com> Message-ID: <20070201163027.GC20332@panik.pesco.prv> Neil Mitchell , 2007-02-01 15.59 +0000: > We're all assuming here that HaXml deliberately decided to change the > interface. Is that really true? (only Malcolm can answer) Yes, I had a glance at it and AFAICT he changed the name of the submodule Text.XML.HaXml.Xml2Haskell to something more suitable. > Most of the time I guess that the interface will change by accident, > without people spotting. Perhaps we are trying to solve the wrong > problem... You have a point, interface change by accident is a different problem. But it doesn't make the other one wrong. Clearly not all interface change is by accident; see above. But without a way for the author to declare it, we're effectively treating all these instances as change by accident as well, which means more maintenance. -Sven From ross at soi.city.ac.uk Thu Feb 1 12:45:19 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Thu Feb 1 12:40:24 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <20070201162944.GB20332@panik.pesco.prv> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> <45C20C06.3060300@cs.chalmers.se> <20070201162944.GB20332@panik.pesco.prv> Message-ID: <20070201174519.GC9034@soi.city.ac.uk> On Thu, Feb 01, 2007 at 05:29:44PM +0100, Sven Moritz Hallberg wrote: > What's wrong with the solution I proposed, i.e. to add an explicit field > to the package description which states whether we broke compatibility > or not? It's effectively the same as a version numbering convention > without having to tell everyone how to assign their numbers. Don't get > me wrong, I'd be all for a consistent numbering scheme. Is everyone else > also? With version numbers, it suffices that each author has a rule of incrementing at a certain level if compatibility is broken. It need not be the same level for different packages (though that would be less confusing). They might have two levels of compatibility: merely adding functions, types or classes will not break any clients that use explicit imports. From ndmitchell at gmail.com Thu Feb 1 12:49:54 2007 From: ndmitchell at gmail.com (Neil Mitchell) Date: Thu Feb 1 12:44:48 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <20070201174519.GC9034@soi.city.ac.uk> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> <45C20C06.3060300@cs.chalmers.se> <20070201162944.GB20332@panik.pesco.prv> <20070201174519.GC9034@soi.city.ac.uk> Message-ID: <404396ef0702010949y2c1904f7la15f71ae5a170646@mail.gmail.com> Hi > With version numbers, it suffices that each author has a rule of > incrementing at a certain level if compatibility is broken. It need > not be the same level for different packages (though that would be > less confusing). They might have two levels of compatibility: merely > adding functions, types or classes will not break any clients that use > explicit imports. We can of course automate this with haddock --hoogle and diff quite easily. It doesn't get it perfectly - if the author changes the semantics or introduces a type alias it won't give the right result, but it should get the answer most of the time. Thanks Neil From sm at khjk.org Thu Feb 1 15:39:22 2007 From: sm at khjk.org (Sven Moritz Hallberg) Date: Thu Feb 1 15:36:38 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <20070201174519.GC9034@soi.city.ac.uk> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> <45C20C06.3060300@cs.chalmers.se> <20070201162944.GB20332@panik.pesco.prv> <20070201174519.GC9034@soi.city.ac.uk> Message-ID: <20070201203922.GA9893@panik.pesco.prv> Ross Paterson , 2007-02-01 17.45 +0000: > With version numbers, it suffices that each author has a rule of > incrementing at a certain level if compatibility is broken. It need > not be the same level for different packages (though that would be > less confusing). > They might have two levels of compatibility: merely > adding functions, types or classes will not break any clients that use > explicit imports. Yes, good point. In fact, I didn't think of the fact that adding functions etc. can also break an importer. :/ It might indeed be a good idea to be able to distinguish these two levels. Already requiring old versions when just an export is added might not offer much benefit to treating all versions incompatible to each other in the first place... Actually, upon pondering the fact that it's impossible to enforce the usage of a particular numbering scheme, it occured to me: We could just make version numbers following the standard scheme (whichever exactly) syntactically distinguishable from the current form. Then cabal-install could work happily with its new information and we don't have to /impose/ a mandatory scheme on everyone. (We could, however, apply some leverage towards "persuading" authors to use the new scheme by emitting a warning from Cabal when it's not used.) Is this a good idea? Suggestions for what "standard-scheme" version numbers could look like? (Coolest look wins!) Regards, Sven From ijones at syntaxpolice.org Sat Feb 3 15:37:42 2007 From: ijones at syntaxpolice.org (Isaac Jones) Date: Sat Feb 3 15:32:27 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <20070201203922.GA9893@panik.pesco.prv> (Sven Moritz Hallberg's message of "Thu, 1 Feb 2007 21:39:22 +0100") References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> <45C20C06.3060300@cs.chalmers.se> <20070201162944.GB20332@panik.pesco.prv> <20070201174519.GC9034@soi.city.ac.uk> <20070201203922.GA9893@panik.pesco.prv> Message-ID: <83fy9n3rl5.fsf@bishop.syntaxpolice.org> The way I propose to solve this version incompatibility problem in the short term is to use the "testing" hackage repository to collect packages that are known to work together. For instance, we could put haxml 1.17 in and only allow things that compile with that version. unstable can still have stuff that only compiles w/ 1.13, but if an author wants their tool to be in "testing", then they have to fix it up to be compatible. (Or we might decide that 1.13 is a better version to have in testing.) This will encouarage people to update their packages with a collection of dependencies that are somewhat "blessed", even if that blessing is a little arbitrary. We can ourselves modify packages so that their version dependency is more accurate than upstream knows them to be :) peace, isaac From duncan.coutts at worc.ox.ac.uk Sat Feb 3 16:04:25 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sat Feb 3 15:59:02 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <83fy9n3rl5.fsf@bishop.syntaxpolice.org> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> <45C20C06.3060300@cs.chalmers.se> <20070201162944.GB20332@panik.pesco.prv> <20070201174519.GC9034@soi.city.ac.uk> <20070201203922.GA9893@panik.pesco.prv> <83fy9n3rl5.fsf@bishop.syntaxpolice.org> Message-ID: <1170536665.29376.167.camel@localhost> On Sat, 2007-02-03 at 12:37 -0800, Isaac Jones wrote: > The way I propose to solve this version incompatibility problem in the > short term is to use the "testing" hackage repository to collect > packages that are known to work together. For instance, we could put > haxml 1.17 in and only allow things that compile with that version. > unstable can still have stuff that only compiles w/ 1.13, but if an > author wants their tool to be in "testing", then they have to fix it > up to be compatible. (Or we might decide that 1.13 is a better > version to have in testing.) > > This will encouarage people to update their packages with a collection > of dependencies that are somewhat "blessed", even if that blessing is > a little arbitrary. > > We can ourselves modify packages so that their version dependency is > more accurate than upstream knows them to be :) It's for issues like this (ie creating a distribution) that having the .cabal file outside the .tar.gz file is a bonus. Let me compare to Gentoo: we provide a distribution of Haskell packages that we test as a group and know that they work together. We test stuff and make sure that the dependencies are sufficiently tight so that things don't break on users' systems. We have an .ebuild file for each package. For a haskell package this obviously duplicates most of the information in the .cabal file, however it gives us an opportunity to make slight corrections. The analogy in hackage is that the .cabal file outside the .tar.gz package can serve as the place where the distributors can 'fix' things. One example of this is the "tested-with:" field, another might be changing "build-depends:" to more tightly constrain version numbers. Duncan From bringert at cs.chalmers.se Sun Feb 4 17:03:19 2007 From: bringert at cs.chalmers.se (Bjorn Bringert) Date: Sun Feb 4 16:55:42 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <83fy9n3rl5.fsf@bishop.syntaxpolice.org> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> <45C20C06.3060300@cs.chalmers.se> <20070201162944.GB20332@panik.pesco.prv> <20070201174519.GC9034@soi.city.ac.uk> <20070201203922.GA9893@panik.pesco.prv> <83fy9n3rl5.fsf@bishop.syntaxpolice.org> Message-ID: <988C2717-A0C5-459D-999B-1ECC49E5E1F1@cs.chalmers.se> On Feb 3, 2007, at 21:37 , Isaac Jones wrote: > The way I propose to solve this version incompatibility problem in the > short term is to use the "testing" hackage repository to collect > packages that are known to work together. For instance, we could put > haxml 1.17 in and only allow things that compile with that version. > unstable can still have stuff that only compiles w/ 1.13, but if an > author wants their tool to be in "testing", then they have to fix it > up to be compatible. (Or we might decide that 1.13 is a better > version to have in testing.) > > This will encouarage people to update their packages with a collection > of dependencies that are somewhat "blessed", even if that blessing is > a little arbitrary. > > We can ourselves modify packages so that their version dependency is > more accurate than upstream knows them to be :) Is there a way to get that working smoothly with the web interface? I guess we could have a separate web interface installation for each "distribution", but maybe some built-in support could make it nicer to use? /Bj?rn From davve at dtek.chalmers.se Sun Feb 4 18:50:09 2007 From: davve at dtek.chalmers.se (davve@dtek.chalmers.se) Date: Sun Feb 4 18:44:52 2007 Subject: darcs patch: Add preliminary support for haddock-ghc (and 7 more) Message-ID: <20070204235009.E1F17442A@anubis.medic.chalmers.se> Fri Sep 15 21:29:49 CEST 2006 davve@dtek.chalmers.se * Add preliminary support for haddock-ghc Fri Dec 29 20:54:39 CET 2006 davve@dtek.chalmers.se * Make sure haddock-ghc really creates the output dir Sun Dec 31 00:21:16 CET 2006 davve@dtek.chalmers.se * Add compilerPath to Paths_ Fri Jan 5 22:22:24 CET 2007 davve@dtek.chalmers.se * Add -D__HADDOCK__ to haddock-ghc Sat Jan 6 02:44:20 CET 2007 davve@dtek.chalmers.se * Generate GHC arguments usable for haddock-ghc Sat Jan 6 02:48:01 CET 2007 davve@dtek.chalmers.se * Use -g option to send GHC arguments to haddock-ghc Thu Jan 18 22:55:20 CET 2007 davve@dtek.chalmers.se * Don't send -cpp to haddock-ghc Mon Feb 5 00:49:25 CET 2007 davve@dtek.chalmers.se * Synch Haddock-GHC changes with recent changes to Cabal -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 39152 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070205/500727fc/attachment-0001.bin From ijones at syntaxpolice.org Sun Feb 4 23:29:15 2007 From: ijones at syntaxpolice.org (Isaac Jones) Date: Sun Feb 4 23:23:57 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <1170536665.29376.167.camel@localhost> (Duncan Coutts's message of "Sat, 03 Feb 2007 21:04:25 +0000") References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <45C1FAD0.9080900@cs.chalmers.se> <20070201154108.GB15706@panik.pesco.prv> <45C20C06.3060300@cs.chalmers.se> <20070201162944.GB20332@panik.pesco.prv> <20070201174519.GC9034@soi.city.ac.uk> <20070201203922.GA9893@panik.pesco.prv> <83fy9n3rl5.fsf@bishop.syntaxpolice.org> <1170536665.29376.167.camel@localhost> Message-ID: <83abzti5wk.fsf@bishop.syntaxpolice.org> Duncan Coutts writes: (snip) >> We can ourselves modify packages so that their version dependency is >> more accurate than upstream knows them to be :) > > It's for issues like this (ie creating a distribution) that having > the .cabal file outside the .tar.gz file is a bonus. > > Let me compare to Gentoo: we provide a distribution of Haskell packages > that we test as a group and know that they work together. We test stuff > and make sure that the dependencies are sufficiently tight so that > things don't break on users' systems. We have an .ebuild file for each > package. For a haskell package this obviously duplicates most of the > information in the .cabal file, however it gives us an opportunity to > make slight corrections. > > The analogy in hackage is that the .cabal file outside the .tar.gz > package can serve as the place where the distributors can 'fix' things. > > One example of this is the "tested-with:" field, another might be > changing "build-depends:" to more tightly constrain version numbers. Debian maintains diffs between the upstream version and the Debian version. It would be nice to do this with darcs instead. What I just did for HAppS, for instance, was update the .cabal file with a description and such, then did a darcs record and forwarded the .cabal file upstream, as well as modifying it within the .tarball that I intend to upload. What would be nice is if this were somehow integrated with darcs, so that I can do a "darcs send" such changes to hackage, which would relay it upstream, as well as keep track of the differences between the upstream version and the Hackage version. peace, isaac From ijones at syntaxpolice.org Sun Feb 4 23:33:10 2007 From: ijones at syntaxpolice.org (Isaac Jones) Date: Sun Feb 4 23:27:51 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <20070201154311.GD15706@panik.pesco.prv> (Sven Moritz Hallberg's message of "Thu, 1 Feb 2007 16:43:11 +0100") References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <20070201154311.GD15706@panik.pesco.prv> Message-ID: <834pq1i5q1.fsf@bishop.syntaxpolice.org> "Sven Moritz Hallberg" writes: > Ross Paterson , 2007-02-01 12.14 +0000: >> We could decide on a standard interpretation of version numbers, e.g. >> major.minor.patch. To support this, we'd want wildcards like 1.13.* >> in version ranges. > > Sounds compelling, but will everyone want/agree to follow that scheme? I think we should just declare such a standard. Very few people care about version numbers outside of ghc-pkg, hackage, and cabal. If we pick something that works for us, I suspect that the majority of people will just go along, as long as it's reasonable. Does anyone want to declare such a standard? :) peace, isaac From bringert at cs.chalmers.se Mon Feb 5 11:41:14 2007 From: bringert at cs.chalmers.se (=?ISO-8859-1?Q?Bj=F6rn_Bringert?=) Date: Mon Feb 5 11:35:54 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <834pq1i5q1.fsf@bishop.syntaxpolice.org> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <20070201154311.GD15706@panik.pesco.prv> <834pq1i5q1.fsf@bishop.syntaxpolice.org> Message-ID: <45C75E2A.40201@cs.chalmers.se> Isaac Jones wrote: > "Sven Moritz Hallberg" writes: > >> Ross Paterson , 2007-02-01 12.14 +0000: >>> We could decide on a standard interpretation of version numbers, e.g. >>> major.minor.patch. To support this, we'd want wildcards like 1.13.* >>> in version ranges. It would be a bit more tedious to type it every time, but wouldn't "HaXml >= 1.13 && < 1.14" be equivalent to "HaXml == 1.13.*"? >> Sounds compelling, but will everyone want/agree to follow that scheme? > > I think we should just declare such a standard. Very few people care > about version numbers outside of ghc-pkg, hackage, and cabal. If we > pick something that works for us, I suspect that the majority of > people will just go along, as long as it's reasonable. > > Does anyone want to declare such a standard? :) Here's a draft based on Ross's proposal above. Please rip it apart. Executive summary: Library package version numbers should be on the format major.minor.revision, where major.minor must change whenever the API changes in a backwards-incompatible way. The revision identifier can have any number of segments, allowing snapshot releases etc. Background: Cabal package version numbers are non-empty sequences of natural numbers, separated by dots. Version numbers are ordered lexicographically. This is a proposed policy for how to assign such version numbers to library releases. Assigning version numbers: Library packages should have version numbers on the format major.minor.revision, where major and minor are natural numbers and revision is a sequence of natural numbers separated by dots. If the revision is the empty sequence, the version number has the format major.minor. Version numbers should be assigned so that software which uses the public API of the library should not be broken by an upgrade to a higher version with the same major.minor combination. Declaring dependencies: Package dependencies should be on a ranges of version numbers such that for each range, the smallest accepted version number is one that the package works with, and the largest accepted number has the same major.minor combination as a version that the package has been determined to work with. For example, if a package has been found to work with foo 1.2.5 (but not 1.2.4) and foo 1.3, the dependency should be declared as "foo >= 1.2.5 && < 1.4". Consequences: - you must change the major.minor number if you release a version where: - you change any exported names, or if you change the type of any exported entity to a type of which the old type is not an instance. - you export an additional name or module. - for each release that needs a new major.minor combinaton, you are free to choose whether to increment the major or the minor number. It is suggested that the major number is incremented when the changes are major. - you are free to choose the revision number scheme. Suggestions for how to assign revision numbers: - Revision numbers could be chosen sequentially, for example using "" (or ".0"), ".1", ".2" etc. - Another level could added to the revision number for snapshot releases, e.g. ".0.20070205", ".0.20070206". - To avoid confusion, it could be a good idea to not use "x.y" and "x.y.0" for different versions. Problems: - Packages will often have their dependencies too tightly specified, since many API changes don't all depending packages. However, having multiple versions of a package installed is probably better than random breakage. - Snapshot releases can't be required to change the major.minor number every time the API changes. Packages could possibly use an odd/even scheme to indicate stability. - Does "the public API" include all exported modules? Or does it exclude semi-public Internals modules etc? - Does "break" include fixing bugs (undocumented behavior) that a depending library relied on? /Bj?rn From fawzi at gmx.ch Mon Feb 5 12:29:41 2007 From: fawzi at gmx.ch (Fawzi Mohamed) Date: Mon Feb 5 12:24:03 2007 Subject: Dependencies/backwards compatibility in Hackage In-Reply-To: <45C75E2A.40201@cs.chalmers.se> References: <20070201115701.GA9097@panik.pesco.prv> <20070201121445.GA9034@soi.city.ac.uk> <20070201154311.GD15706@panik.pesco.prv> <834pq1i5q1.fsf@bishop.syntaxpolice.org> <45C75E2A.40201@cs.chalmers.se> Message-ID: > [...] > Here's a draft based on Ross's proposal above. Please rip it apart. > > > Executive summary: > > Library package version numbers should be on the format > major.minor.revision, where major.minor must change whenever the > API changes in a backwards-incompatible way. The revision > identifier can have any number of segments, allowing snapshot > releases etc. As I said I really like the method used for frameworks on MacOSX (or for some libraries on linux) which is described here http://developer.apple.com/documentation/MacOSX/Conceptual/ BPFrameworks/Concepts/VersionInformation.html major: The major number means non backward compatible change, and is part of the name (on linux you see for example libreadline.5.so where 5 is the major revision). It is possible to have more than one major revision installed (very useful during transitions) minor: backward compatible change (additions to the api, bug-fix,...) revision: bug-fixes, development (can be absent), I would like to have this a lexicographically ordered string, so that one could use a date YYYYMMDDTHHMM plus some other "snapshot defining" string, or add a fourth non ordered string value now when a modules says that it needs 3.4.5 it means major=3, minor>=4, (if minor==4 rev>=5). I like the idea of having a tool that checkes the interface changes and automatically says if one should change minor or major version (it would work most of the time I think, and be very useful). > [...]Declaring dependencies: > > Package dependencies should be on a ranges of version numbers such > that for each range, the smallest accepted version number is one > that the package works with, and the largest accepted number has > the same major.minor combination as a version that the package has > been determined to work with. For example, if a package has been > found to work with foo 1.2.5 (but not 1.2.4) and foo 1.3, the > dependency should be declared as "foo >= 1.2.5 && < 1.4". a problem with this is that how much it works with future releases is difficult to predict. I major version change specifies a non backward compatible change there is a meaningful default: if not specified the package will not work with different major vesions, but will work with (higher) minor versions. > - for each release that needs a new major.minor combinaton, you are > free to choose whether to increment the major or the minor number. > It is suggested that the major number is incremented when the > changes are major. for the resons utlined before unless other feel that it is a too big ingerence in the version numbering I think that non backward comaptible changes should always increment the major number. > Suggestions for how to assign revision numbers: > > - Revision numbers could be chosen sequentially, for example using > "" (or ".0"), ".1", ".2" etc. > > - Another level could added to the revision number for snapshot > releases, e.g. ".0.20070205", ".0.20070206". > > - To avoid confusion, it could be a good idea to not use "x.y" and > "x.y.0" for different versions. > > > Problems: > > - Packages will often have their dependencies too tightly > specified, since many API changes don't all depending packages. > However, having multiple versions of a package installed is > probably better than random breakage. > > - Snapshot releases can't be required to change the major.minor > number every time the API changes. Packages could possibly use an > odd/even scheme to indicate stability. maybe one could add a stability flag, or add unstable to the revision string > - Does "the public API" include all exported modules? Or does it > exclude semi-public Internals modules etc? Exported modules has the advantage of being easily checkable, but I would allow for extensions of the private api to have the same minor number, otherwise development could be more difficult. On the other hand a hard approach to it might have advantages, published modules should respect the rules. Maybe here a stability flag could be useful. > - Does "break" include fixing bugs (undocumented behavior) that a > depending library relied on? I would say no, unless it is something that is expected to give major problems. If problems arise in a package one should modify its compatibility range. Fawzi From duncan.coutts at worc.ox.ac.uk Mon Feb 12 04:36:42 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Mon Feb 12 04:27:47 2007 Subject: patch applied (cabal): add --enable-optimization/--disable-optimization config options (on by default) In-Reply-To: <20070212004619.GA21561@cvs.haskell.org> References: <20070212004619.GA21561@cvs.haskell.org> Message-ID: <1171273003.23819.107.camel@localhost> On Sun, 2007-02-11 at 16:46 -0800, Ross Paterson wrote: > Sun Feb 11 16:45:13 PST 2007 Ross Paterson > * add --enable-optimization/--disable-optimization config options (on by default) > > M ./Distribution/Setup.hs +9 > M ./Distribution/Simple/Configure.hs +1 > M ./Distribution/Simple/GHC.hs +1 > M ./Distribution/Simple/LocalBuildInfo.hs +1 > M ./doc/Cabal.xml +18 This is great (I kept meaning to get round to it!) but I'm not sure it should be on by default. Certainly it should be used by cabal-install since that is a user tool for installing a package, but developers use the Seyup.hs or cabal-setup tools directly and they will not want -O to be on by default I think. If they were building it to install then they'd use the other tool, so if they're using the dev tool then it's likely because they want to do some development work and so will want a shorter build time. (Similarly, profiling is off for Setup.hs/cabal-setup but perhaps should be on by default for cabal-install) Am I wrong? What do other people reckon? Duncan From simonmarhaskell at gmail.com Mon Feb 12 06:27:50 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Feb 12 06:22:10 2007 Subject: darcs patch: Add preliminary support for haddock-ghc (and 7 more) In-Reply-To: <20070204235009.E1F17442A@anubis.medic.chalmers.se> References: <20070204235009.E1F17442A@anubis.medic.chalmers.se> Message-ID: <45D04F36.7040101@gmail.com> davve@dtek.chalmers.se wrote: > Fri Sep 15 21:29:49 CEST 2006 davve@dtek.chalmers.se > * Add preliminary support for haddock-ghc Hi David, I had a quick chat with Duncan about this today, and we think perhaps a smoother transition path would be for haddock-ghc to be called simply "Haddock 2.0", since we intend it to be a replacement for the current generation of Haddock. So then Cabal would test the version of Haddock you have in order to decide how to invoke it, and you can already select which Haddock binary you want to use with the --with-haddock flag. How does that sound? Would you like to update the patches? Cheers, Simon From davve at dtek.chalmers.se Mon Feb 12 10:48:51 2007 From: davve at dtek.chalmers.se (David Waern) Date: Mon Feb 12 10:43:10 2007 Subject: darcs patch: Add preliminary support for haddock-ghc (and 7 more) In-Reply-To: <45D04F36.7040101@gmail.com> References: <20070204235009.E1F17442A@anubis.medic.chalmers.se> <45D04F36.7040101@gmail.com> Message-ID: 12 feb 2007 kl. 12.27 skrev Simon Marlow: > davve@dtek.chalmers.se wrote: >> Fri Sep 15 21:29:49 CEST 2006 davve@dtek.chalmers.se >> * Add preliminary support for haddock-ghc > > Hi David, > > I had a quick chat with Duncan about this today, and we think > perhaps a smoother transition path would be for haddock-ghc to be > called simply "Haddock 2.0", since we intend it to be a replacement > for the current generation of Haddock. > > So then Cabal would test the version of Haddock you have in order > to decide how to invoke it, and you can already select which > Haddock binary you want to use with the --with-haddock flag. > > How does that sound? Would you like to update the patches? > > Cheers, > Simon That's sounds good. I'll update the patches later. /David From dons at cse.unsw.edu.au Mon Feb 12 18:51:38 2007 From: dons at cse.unsw.edu.au (Donald Bruce Stewart) Date: Mon Feb 12 18:46:10 2007 Subject: patch applied (cabal): add --enable-optimization/--disable-optimization config options (on by default) In-Reply-To: <1171273003.23819.107.camel@localhost> References: <20070212004619.GA21561@cvs.haskell.org> <1171273003.23819.107.camel@localhost> Message-ID: <20070212235138.GD3147@cse.unsw.EDU.AU> duncan.coutts: > On Sun, 2007-02-11 at 16:46 -0800, Ross Paterson wrote: > > Sun Feb 11 16:45:13 PST 2007 Ross Paterson > > * add --enable-optimization/--disable-optimization config options (on by default) > > > > M ./Distribution/Setup.hs +9 > > M ./Distribution/Simple/Configure.hs +1 > > M ./Distribution/Simple/GHC.hs +1 > > M ./Distribution/Simple/LocalBuildInfo.hs +1 > > M ./doc/Cabal.xml +18 > > This is great (I kept meaning to get round to it!) but I'm not sure it > should be on by default. Certainly it should be used by cabal-install > since that is a user tool for installing a package, but developers use > the Seyup.hs or cabal-setup tools directly and they will not want -O to > be on by default I think. If they were building it to install then > they'd use the other tool, so if they're using the dev tool then it's > likely because they want to do some development work and so will want a > shorter build time. I think developers can be expected to read the docs and turn off optimisations if they like. Everyone else should get -O by default, to avoid bad press ;-) it's easy enough for a developer to alias build="runhaskell Setup --disable-optimization" -- Don From ijones at syntaxpolice.org Tue Feb 13 14:44:56 2007 From: ijones at syntaxpolice.org (Isaac Jones) Date: Tue Feb 13 14:39:12 2007 Subject: [Conal Elliott] Re: Fwd: cabal-make almost ready Message-ID: <83k5ylx2o7.fsf@bishop.syntaxpolice.org> An embedded message was scrubbed... From: "Conal Elliott" Subject: Re: Fwd: cabal-make almost ready Date: Sat, 3 Feb 2007 22:25:27 -0800 Size: 40742 Url: http://www.haskell.org/pipermail/cabal-devel/attachments/20070213/d4c80738/attachment-0001.eml From igloo at earth.li Sun Feb 18 12:18:48 2007 From: igloo at earth.li (Ian Lynagh) Date: Sun Feb 18 12:12:47 2007 Subject: patch applied (cabal): add --enable-optimization/--disable-optimization config options (on by default) In-Reply-To: <20070212235138.GD3147@cse.unsw.EDU.AU> References: <20070212004619.GA21561@cvs.haskell.org> <1171273003.23819.107.camel@localhost> <20070212235138.GD3147@cse.unsw.EDU.AU> Message-ID: <20070218171848.GA11708@matrix.chaos.earth.li> On Tue, Feb 13, 2007 at 10:51:38AM +1100, Donald Bruce Stewart wrote: > > I think developers can be expected to read the docs and turn off > optimisations if they like. Everyone else should get -O by default, to > avoid bad press ;-) Since Duncan asked for opinions, I agree with Don. Thanks Ian From duncan.coutts at worc.ox.ac.uk Sun Feb 18 12:51:37 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Sun Feb 18 12:45:32 2007 Subject: patch applied (cabal): add --enable-optimization/--disable-optimization config options (on by default) In-Reply-To: <20070218171848.GA11708@matrix.chaos.earth.li> References: <20070212004619.GA21561@cvs.haskell.org> <1171273003.23819.107.camel@localhost> <20070212235138.GD3147@cse.unsw.EDU.AU> <20070218171848.GA11708@matrix.chaos.earth.li> Message-ID: <1171821097.1018.131.camel@localhost> On Sun, 2007-02-18 at 17:18 +0000, Ian Lynagh wrote: > On Tue, Feb 13, 2007 at 10:51:38AM +1100, Donald Bruce Stewart wrote: > > > > I think developers can be expected to read the docs and turn off > > optimisations if they like. Everyone else should get -O by default, to > > avoid bad press ;-) > > Since Duncan asked for opinions, I agree with Don. Ok, fair enough. Should --enable-optimisation also enable split-objs ? If --enable-optimisation is about building for installation then we'd want that too I'd assume. We've got a separate --enable/--disable flag for split-objs but perhaps the default for that flag should depend on the optimisation flag. Duncan From simonmarhaskell at gmail.com Mon Feb 19 07:34:16 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Mon Feb 19 07:28:13 2007 Subject: patch applied (cabal): add --enable-optimization/--disable-optimization config options (on by default) In-Reply-To: <20070218171848.GA11708@matrix.chaos.earth.li> References: <20070212004619.GA21561@cvs.haskell.org> <1171273003.23819.107.camel@localhost> <20070212235138.GD3147@cse.unsw.EDU.AU> <20070218171848.GA11708@matrix.chaos.earth.li> Message-ID: <45D99948.9020701@gmail.com> Ian Lynagh wrote: > On Tue, Feb 13, 2007 at 10:51:38AM +1100, Donald Bruce Stewart wrote: >> I think developers can be expected to read the docs and turn off >> optimisations if they like. Everyone else should get -O by default, to >> avoid bad press ;-) > > Since Duncan asked for opinions, I agree with Don. Me too, and this corresponds with what GHC does: by default you get a fully optimised build, ready for installation. I think this is more or less standard practice, isn't it? Cheers, Simon From ross at soi.city.ac.uk Mon Feb 19 12:36:58 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Feb 19 12:30:53 2007 Subject: [Conal Elliott] Re: getting cabal to pass more info to haddock In-Reply-To: References: <83vej5fvrq.fsf@bishop.syntaxpolice.org> <837ivlfv90.fsf@bishop.syntaxpolice.org> Message-ID: <20070219173658.GA15877@soi.city.ac.uk> On Fri, Jan 19, 2007 at 05:18:07PM -0800, Conal Elliott wrote: > So now I have just a new pair of flags enable-use-packages & > disable-use-packages, which control whether haddock gets > automatically-generated --use-package flags. There's a similar (but simpler) problem with generating Haddock documentation for HackageDB. The trouble is that --use-package is half right: it gives the interface file you want, but the wrong URL for cross-references. (And there's no way to override it, because haddock doesn't know which package a --read-interface option relates to.) For HackageDB, I think the appropriate thing would be for Cabal to use ghc-pkg to get the haddock-interfaces field (instead of asking haddock to ask ghc-pkg for it), but for the user to be able to override the HTML URL at configure time. For HackageDB, a suitable template would be http://hackage.haskell.org/packages/archive/$pkg/$pkgid.misc/doc/html or http://hackage.haskell.org/packages/archive/$pkg/latest.misc/doc/html That wouldn't work for Conal's situation, where the URLs for his own packages point at a different place than the ones distributed with GHC. From conal at conal.net Mon Feb 19 18:04:24 2007 From: conal at conal.net (Conal Elliott) Date: Mon Feb 19 17:58:18 2007 Subject: [Conal Elliott] Re: getting cabal to pass more info to haddock In-Reply-To: <20070219173658.GA15877@soi.city.ac.uk> References: <83vej5fvrq.fsf@bishop.syntaxpolice.org> <837ivlfv90.fsf@bishop.syntaxpolice.org> <20070219173658.GA15877@soi.city.ac.uk> Message-ID: I love this idea. Having to specify the local interface file is a major defect of my solution. I'd much rather specify just the URL for the external library docs. I'd also be happy to adopt some convention about where to put such docs so they could be determined automatically. Perhaps via indirection where necessary. Then my per-project makefile content would vanish altogether. Ross: I don't understand the last remark below about my requirements differ from HackageDB's. - Conal On 2/19/07, Ross Paterson wrote: > > On Fri, Jan 19, 2007 at 05:18:07PM -0800, Conal Elliott wrote: > > So now I have just a new pair of flags enable-use-packages & > > disable-use-packages, which control whether haddock gets > > automatically-generated --use-package flags. > > There's a similar (but simpler) problem with generating Haddock > documentation for HackageDB. The trouble is that --use-package is > half right: it gives the interface file you want, but the wrong URL for > cross-references. (And there's no way to override it, because haddock > doesn't know which package a --read-interface option relates to.) > > For HackageDB, I think the appropriate thing would be for Cabal to use > ghc-pkg to get the haddock-interfaces field (instead of asking haddock to > ask ghc-pkg for it), but for the user to be able to override the HTML URL > at configure time. For HackageDB, a suitable template would be > > > http://hackage.haskell.org/packages/archive/$pkg/$pkgid.misc/doc/html > or > > http://hackage.haskell.org/packages/archive/$pkg/latest.misc/doc/html > > That wouldn't work for Conal's situation, where the URLs for his own > packages point at a different place than the ones distributed with GHC. > > _______________________________________________ > cabal-devel mailing list > cabal-devel@haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/cabal-devel/attachments/20070219/30a0cb56/attachment.htm From ross at soi.city.ac.uk Mon Feb 19 18:56:50 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Feb 19 18:50:57 2007 Subject: [Conal Elliott] Re: getting cabal to pass more info to haddock In-Reply-To: References: <83vej5fvrq.fsf@bishop.syntaxpolice.org> <837ivlfv90.fsf@bishop.syntaxpolice.org> <20070219173658.GA15877@soi.city.ac.uk> Message-ID: <20070219235650.GA24081@soi.city.ac.uk> On Mon, Feb 19, 2007 at 03:04:24PM -0800, Conal Elliott wrote: > I love this idea. Having to specify the local interface file is a major > defect of my solution. I'd much rather specify just the URL for the > external library docs. I'd also be happy to adopt some convention about > where to put such docs so they could be determined automatically. Perhaps > via indirection where necessary. Then my per-project makefile content would > vanish altogether. > > Ross: I don't understand the last remark below about my requirements differ > from HackageDB's. I was thinking of a single option to specify a template for the URL (pointing at docs generated by HackageDB), whereas you'd need two different templates for your cross-references: http://darcs.haskell.org/packages/$pkg/doc/html http://haskell.org/ghc/docs/latest/html/libraries/$pkg But we could set up a directory on haskell.org to unify those. In the longer term, maybe some day HackageDB will be generating something you'd be happy to use. From ross at soi.city.ac.uk Mon Feb 19 19:02:52 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Mon Feb 19 18:56:48 2007 Subject: [Conal Elliott] Re: getting cabal to pass more info to haddock In-Reply-To: <20070219173658.GA15877@soi.city.ac.uk> References: <83vej5fvrq.fsf@bishop.syntaxpolice.org> <837ivlfv90.fsf@bishop.syntaxpolice.org> <20070219173658.GA15877@soi.city.ac.uk> Message-ID: <20070220000252.GB24081@soi.city.ac.uk> On Mon, Feb 19, 2007 at 05:36:58PM +0000, Ross Paterson wrote: > For HackageDB, I think the appropriate thing would be for Cabal to use > ghc-pkg to get the haddock-interfaces field (instead of asking haddock to > ask ghc-pkg for it), but for the user to be able to override the HTML URL > at configure time. Another reason for Cabal to call ghc-pkg instead of asking haddock to is to ensure that it is the same ghc-pkg that we specified to Cabal, rather than the one haddock plucks out of the environment. From bos at serpentine.com Tue Feb 20 18:39:37 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Feb 20 18:31:37 2007 Subject: Added RPM generation capability to Cabal Message-ID: <45DB86B9.2060603@serpentine.com> I spent a few hours over the past couple of days hacking on Cabal to add the ability to build RPM packages. You can fetch my darcs repository from here: darcs get --partial http://darcs.serpentine.com/cabal-rpm This new capability is easy to use. It adds a single new Cabal command, called rpm. runhaskell Setup.*hs rpm This generates a spec file, and builds source and binary RPMs. Here?s a quick example, of trying to build the Haskell XML-RPC library: ~/src/darcs/haxr $ runghc Setup.*hs rpm Source tarball created: dist/SOURCES/haxr-3000.0.0.tar.gz error: Failed build dependencies: HaXml-ghc66 >= 1.13 is needed by haxr-3000.0.0-1.i386 HaXml-ghc66 < 1.14 is needed by haxr-3000.0.0-1.i386 Setup.lhs: rpmbuild failed with status 1 The rpm command has converted the dependencies in the haxr.cabal file into build-time and runtime dependencies in the haxr.spec file that it generated, but rpmbuild can?t find the HaXml package. Having earlier built a HaXml package using the rpm command, I can install it with the system?s rpm command. # rpm -i haxml-ghc66-1.13.2-1.i386.rpm Reading package info from stdin ... done. Saving old package config file... done. Writing new package config file... done. The RPM?s post-install scriptlet informs GHC?s package manager about the package?s availability: # ghc-pkg list --simple | tr ' ' '\n' | grep -i haxml HaXml-1.13.2 Now if I try to build haxr again, it will succeed. By default, the rpm command builds both normal and profiling-enabled libraries. It also uses Haddock to generate library documentation. It?s possible to control these behaviours from the command line. The command also provides a --gen-spec option, which only generates a spec file. You can use this >spec file as a basis for crafting one of your own. I?ve used the rpm command to build about a third of the packages listed in the Hackage package database, with no problems. From duncan.coutts at worc.ox.ac.uk Tue Feb 20 18:51:08 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 20 18:44:54 2007 Subject: Added RPM generation capability to Cabal In-Reply-To: <45DB86B9.2060603@serpentine.com> References: <45DB86B9.2060603@serpentine.com> Message-ID: <1172015468.1018.203.camel@localhost> Great stuff Bryan, I look forward to seeing the patches. Do darcs send them to this list for review. Duncan On Tue, 2007-02-20 at 15:39 -0800, Bryan O'Sullivan wrote: > I spent a few hours over the past couple of days hacking on Cabal to add > the ability to build RPM packages. You can fetch my darcs repository > from here: > > darcs get --partial http://darcs.serpentine.com/cabal-rpm > > This new capability is easy to use. It adds a single new Cabal command, > called rpm. > > runhaskell Setup.*hs rpm > > This generates a spec file, and builds source and binary RPMs. > > Here?s a quick example, of trying to build the Haskell XML-RPC library: > > ~/src/darcs/haxr $ runghc Setup.*hs rpm > Source tarball created: dist/SOURCES/haxr-3000.0.0.tar.gz > error: Failed build dependencies: > HaXml-ghc66 >= 1.13 is needed by haxr-3000.0.0-1.i386 > HaXml-ghc66 < 1.14 is needed by haxr-3000.0.0-1.i386 > Setup.lhs: rpmbuild failed with status 1 > > The rpm command has converted the dependencies in the haxr.cabal file > into build-time and runtime dependencies in the haxr.spec file that it > generated, but rpmbuild can?t find the HaXml package. > > Having earlier built a HaXml package using the rpm command, I can > install it with the system?s rpm command. > > # rpm -i haxml-ghc66-1.13.2-1.i386.rpm > Reading package info from stdin ... done. > Saving old package config file... done. > Writing new package config file... done. > > The RPM?s post-install scriptlet informs GHC?s package manager about the > package?s availability: > > # ghc-pkg list --simple | tr ' ' '\n' | grep -i haxml > HaXml-1.13.2 > > Now if I try to build haxr again, it will succeed. > > By default, the rpm command builds both normal and profiling-enabled > libraries. It also uses Haddock to generate library documentation. It?s > possible to control these behaviours from the command line. > > The command also provides a --gen-spec option, which only generates a > spec file. You can use this >spec file as a basis for crafting one of > your own. > > I?ve used the rpm command to build about a third of the packages listed > in the Hackage package database, with no problems. > _______________________________________________ > cabal-devel mailing list > cabal-devel@haskell.org > http://www.haskell.org/mailman/listinfo/cabal-devel From ijones at syntaxpolice.org Tue Feb 20 18:52:30 2007 From: ijones at syntaxpolice.org (Isaac Jones) Date: Tue Feb 20 18:46:22 2007 Subject: Added RPM generation capability to Cabal In-Reply-To: <45DB86B9.2060603@serpentine.com> (Bryan O'Sullivan's message of "Tue, 20 Feb 2007 15:39:37 -0800") References: <45DB86B9.2060603@serpentine.com> Message-ID: <83fy90qtdt.fsf@bishop.syntaxpolice.org> Have you seen cabal2rpm? It's an external tool with a similar goal: http://community.moertel.com/ss/space/Cabal2rpm/cabal2rpm.html Similarly, there's dh_haskell for Debian packages: http://man.cx/dh_haskell(1) Can you outline any other differences between this command and cabal2rpm? This seems like really cool work, but what do folks think about adding OS-specific items like this to Cabal. My stance has been that we should keep such tools external to Cabal, layered on top of Cabal so as to not clutter Cabal too much, and to make Cabal's interface to the outside world as good as possible. peace, isaac From bos at serpentine.com Tue Feb 20 19:36:38 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Feb 20 19:28:38 2007 Subject: Added RPM generation capability to Cabal In-Reply-To: <1172015468.1018.203.camel@localhost> References: <45DB86B9.2060603@serpentine.com> <1172015468.1018.203.camel@localhost> Message-ID: <45DB9416.9080204@serpentine.com> Duncan Coutts wrote: > Great stuff Bryan, I look forward to seeing the patches. Do darcs send > them to this list for review. I'd be happy to, but my darcs repo contains about 50 patches that resulted from many incremental checkpoints as I went. I'm guessing that you'd prefer to see something closer to three or four? My darcs fu is not strong enough to know whether there's an easy way to do this, so I may end up having to diff my branch with the main repository and repatch. References: <45DB86B9.2060603@serpentine.com> <1172015468.1018.203.camel@localhost> <45DB9416.9080204@serpentine.com> Message-ID: <20070221004148.GA3522@localhost.localdomain> On Tue, Feb 20, 2007 at 04:36:38PM -0800, Bryan O'Sullivan wrote: > Duncan Coutts wrote: > >Great stuff Bryan, I look forward to seeing the patches. Do darcs send > >them to this list for review. > > I'd be happy to, but my darcs repo contains about 50 patches that > resulted from many incremental checkpoints as I went. I'm guessing that > you'd prefer to see something closer to three or four? > > My darcs fu is not strong enough to know whether there's an easy way to > do this, so I may end up having to diff my branch with the main > repository and repatch. As I recall, it is considered a major feature of darcs that patches retain their identity on merging - if something breaks, you can unrecord only a small piece, even after the merge. Besides, remember that 50 patches is 50x the documentation :) From bos at serpentine.com Tue Feb 20 19:49:04 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Feb 20 19:41:02 2007 Subject: Trac has me baffled Message-ID: <45DB9700.3040302@serpentine.com> I'd like to file a bug against Cabal, but I cannot for the life of me figure out how to create an account at http://hackage.haskell.org/trac/hackage/ If there is a "create an account" knob somewhere, I cannot see it. For the record, the bug is that the sdist command doesn't archive files listed in "install-includes" to a tarball. The result is that if you try to build a tree unpacked from sdist, it will fail. I've seen this with a few packages. (Bryan O'Sullivan's message of "Tue, 20 Feb 2007 16:49:04 -0800") References: <45DB9700.3040302@serpentine.com> Message-ID: <83zm78pbb6.fsf@bishop.syntaxpolice.org> "Bryan O'Sullivan" writes: > I'd like to file a bug against Cabal, but I cannot for the life of me > figure out how to create an account at > http://hackage.haskell.org/trac/hackage/ Login: guest password: haskell' (note the apostrophe at the end) I had to disable "create an account" nobs due to evil spammers. peace, isaac From bos at serpentine.com Tue Feb 20 20:15:55 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Feb 20 20:07:56 2007 Subject: Added RPM generation capability to Cabal In-Reply-To: <20070221004148.GA3522@localhost.localdomain> References: <45DB86B9.2060603@serpentine.com> <1172015468.1018.203.camel@localhost> <45DB9416.9080204@serpentine.com> <20070221004148.GA3522@localhost.localdomain> Message-ID: <45DB9D4B.5020709@serpentine.com> Stefan O'Rear wrote: > Besides, remember that 50 patches is > 50x the documentation :) Yes, but it's 50x the blundering about when trying to review the code :-) Here's a seemingly reasonable compromise. I've attached a single unified diff that contains all of my changes in a single lump. If the code looks sane, you can then "darcs pull" the real changes and see if the history "smells right". There shouldn't be any review surprises. The only "unrelated" change it makes is to check the return code from tar in SrcDist, something that must have been overlooked. The actual darcs history is pretty clean, too. Small, self-contained changes, etc, etc. References: <45DB86B9.2060603@serpentine.com> <83fy90qtdt.fsf@bishop.syntaxpolice.org> Message-ID: <200702210419.25102.nanardon@nanardon.zarb.org> Le Wednesday 21 February 2007, Isaac Jones a ?crit?: > Have you seen cabal2rpm? ?It's an external tool with a similar goal: I did also mine, but according my haskell knowledge, I'd better to have a look to already existing project. I am myself a Mandriva contributor, and I started to package some haskell module, and plan to increase the count. But if all thoses project want to have a sex appeal, they should be configurable per distribution to apply their policy. For example, at mandriva our rpm are in svn, the spec is generated once, and then update, like in many distribution, the official "Group" list differ, and finally we all use macros. Hit me if you want to know how to improve them to make them really usefull. Such project are a good idea anyway. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://www.haskell.org/pipermail/cabal-devel/attachments/20070221/a6e30cda/attachment.bin From bos at serpentine.com Tue Feb 20 23:56:00 2007 From: bos at serpentine.com (Bryan O'Sullivan) Date: Tue Feb 20 23:49:50 2007 Subject: Added RPM generation capability to Cabal In-Reply-To: <200702210419.25102.nanardon@nanardon.zarb.org> References: <45DB86B9.2060603@serpentine.com> <83fy90qtdt.fsf@bishop.syntaxpolice.org> <200702210419.25102.nanardon@nanardon.zarb.org> Message-ID: <45DBD0E0.10002@serpentine.com> > Have you seen cabal2rpm? It's an external tool with a similar goal: > > http://community.moertel.com/ss/space/Cabal2rpm/cabal2rpm.html I hadn't seen it, no. > Can you outline any other differences between this command and > cabal2rpm? Cabal2rpm is much less sophisticated. The rpm command I wrote correctly calculates dependencies on other Haskell packages, and on system packages too. Also, cabal2rpm has clearly bitrotted from looking at the source, and would be unlikely to work now. > This seems like really cool work, but what do folks think about adding > OS-specific items like this to Cabal. I realise I get a bit less of a vote since I wrote this, but I think that cabal2rpm illustrates one aspect of the problem with keeping tools like this outside of Cabal: they break. Another aspect is that you have to be able to *find* the external tools. A Google search like "cabal rpm spec" does not yield cabal2rpm anywhere in the results. > My stance has been that we > should keep such tools external to Cabal, layered on top of Cabal so > as to not clutter Cabal too much, and to make Cabal's interface to the > outside world as good as possible. I certainly wouldn't mind there being a single command entry point for building binary packages, e.g. bdist, with flags to control which kind of binary package to build (RPM, deb, DMG, Innosetup, etc.). But I really think it's a good thing for the language as a whole to make it as easy as possible for people to provide binaries to their respective OS/distro communities. This is a step towards that. I've written Mac and Windows installers, too, so if the RPM stuff gets in, they're natural targets. You can see that the code I added has negligible effect on the core of Cabal, so it doesn't add clutter. References: <45DB9700.3040302@serpentine.com> <83zm78pbb6.fsf@bishop.syntaxpolice.org> Message-ID: <20070221071518.GA3373@soi.city.ac.uk> On Tue, Feb 20, 2007 at 05:08:13PM -0800, Isaac Jones wrote: > "Bryan O'Sullivan" writes: > > I'd like to file a bug against Cabal, but I cannot for the life of me > > figure out how to create an account at > > http://hackage.haskell.org/trac/hackage/ > > Login: guest > password: haskell' > (note the apostrophe at the end) That wierd password keeps tripping people up. Could you change it? From simonmarhaskell at gmail.com Wed Feb 21 08:13:51 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Feb 21 08:07:41 2007 Subject: Added RPM generation capability to Cabal In-Reply-To: <83fy90qtdt.fsf@bishop.syntaxpolice.org> References: <45DB86B9.2060603@serpentine.com> <83fy90qtdt.fsf@bishop.syntaxpolice.org> Message-ID: <45DC458F.8050502@gmail.com> Isaac Jones wrote: > Have you seen cabal2rpm? It's an external tool with a similar goal: > > http://community.moertel.com/ss/space/Cabal2rpm/cabal2rpm.html > > Similarly, there's dh_haskell for Debian packages: > http://man.cx/dh_haskell(1) > > Can you outline any other differences between this command and > cabal2rpm? > > This seems like really cool work, but what do folks think about adding > OS-specific items like this to Cabal. My stance has been that we > should keep such tools external to Cabal, layered on top of Cabal so > as to not clutter Cabal too much, and to make Cabal's interface to the > outside world as good as possible. The problem with layered tools is that they don't work well with the Setup.lhs scheme that we currently have. Setup.lhs can modify PackageDescription via hooks, so the layered tool won't see these modifications. I suspect that in practice there are hardly any clashes of this kind, though. To properly support this we would have to provide a way to output the modified PackageDescription so the tool can read it in. On the other hand, every time we add a new command (like 'Setup rpm') we need a new hook, which breaks the Cabal API again: existing packages which use hooks probably wanted to also hook the new command. The current design for hooks doesn't extend well, we should think about that. FWIW, I'd let the RPM patch in for now. Cheers, Simon From ross at soi.city.ac.uk Wed Feb 21 19:47:15 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Wed Feb 21 19:41:07 2007 Subject: #112: Documention error (should be easy to fix) Message-ID: <20070222004715.GA25554@soi.city.ac.uk> The documentation is wrong, but what's actually happening is that "setup configure" takes a --with-compiler option, but changes that into a --with-hc option when calling configure. That's pretty gross, and I don't think anyone is using the --with-hc option: should we just change it to --with-compiler for simplicity? From igloo at earth.li Thu Feb 22 06:58:13 2007 From: igloo at earth.li (Ian Lynagh) Date: Thu Feb 22 06:56:50 2007 Subject: Added RPM generation capability to Cabal In-Reply-To: <83fy90qtdt.fsf@bishop.syntaxpolice.org> References: <45DB86B9.2060603@serpentine.com> <83fy90qtdt.fsf@bishop.syntaxpolice.org> Message-ID: <20070222115813.GA14851@matrix.chaos.earth.li> On Tue, Feb 20, 2007 at 03:52:30PM -0800, Isaac Jones wrote: > > This seems like really cool work, but what do folks think about adding > OS-specific items like this to Cabal. My stance has been that we > should keep such tools external to Cabal, layered on top of Cabal so > as to not clutter Cabal too much, and to make Cabal's interface to the > outside world as good as possible. FWIW, I agree. Also, having the rpm code built with cabal will only ensure it keeps compiling. I won't necessarily keep it correct, and in my experience it is also common to see "temporary" (error "unhandled case")s appear in such situations, where many contributors are not interested in the rpm code, and are unable to easily test it. Thanks Ian From ross at soi.city.ac.uk Tue Feb 27 12:31:16 2007 From: ross at soi.city.ac.uk (Ross Paterson) Date: Tue Feb 27 12:24:46 2007 Subject: merge problem Message-ID: <20070227173116.GA8850@soi.city.ac.uk> The HEAD version of Cabal contains a rather large patch called "Refactorings only", which inadvertantly fixed a bug: the 6.6 version rejects a Cabal file that contains unknown fields but no library. It would be handy if that bug could be fixed in the 6.6 version too. Would it be best to make a subset of the patch? From duncan.coutts at worc.ox.ac.uk Tue Feb 27 16:00:13 2007 From: duncan.coutts at worc.ox.ac.uk (Duncan Coutts) Date: Tue Feb 27 15:53:33 2007 Subject: merge problem In-Reply-To: <20070227173116.GA8850@soi.city.ac.uk> References: <20070227173116.GA8850@soi.city.ac.uk> Message-ID: <1172610013.1018.343.camel@localhost> On Tue, 2007-02-27 at 17:31 +0000, Ross Paterson wrote: > The HEAD version of Cabal contains a rather large patch called > "Refactorings only", which inadvertantly fixed a bug: the 6.6 version > rejects a Cabal file that contains unknown fields but no library. > It would be handy if that bug could be fixed in the 6.6 version too. > > Would it be best to make a subset of the patch? Yes, it'd be good to fix that in the 1.1.6 branch without also merging the other general refactoring. http://darcs.haskell.org/cabal-branches/cabal-1.1.6/ Duncan