On 30 September 2012 05:26, Bryan O'Sullivan <b...@serpentine.com> wrote: > On Fri, Sep 28, 2012 at 5:55 PM, Duncan Coutts > <duncan.cou...@googlemail.com> wrote: >> >> Being able to do this relies on both editing on the server, and for >> the client to actually use the updated .cabal file. So this patch >> provides the client side part of the feature. The server side already >> works (we've actually made quite a few edits to .cabal files on >> hackage post-release) but the UI for it will improve significantly in >> the new server which we expect to go live during the lifetime of this >> next cabal-install release. So getting the feature in now would be a >> real help to everyone (and ideally, most users will never notice). > > > This feels like a big piece of work to be pushing in right before a release. > > It worries me because now there's an invisible piece of metadata floating > around that neither OS packagers nor library maintainers can see. In a way, > this feels strictly worse than having a package just plain break, because > it's not hard to imagine a cycle of "package breaks; magic invisible > dependency update silently fixes it; new version is released; package > re-breaks because maintainer never found out about previous breakage". > > I could be convinced that in fact everything is going to be awesome and it > will all somehow work, but in the short term I'd prefer to delay sprinkling > invisible dependency pixie dust on packages, and let this wait until the > next release, 3 months down the line.
I realise there's more to the management side of this feature. But that's something that mostly has to be implemented on the hackage side of things. There's not that much that needs to be in the client. So I'd prefer to have clients support this early, and we can work on the management issues on the server. In particular, hackage will keep track of the revision, and this will be reflected in the .cabal file. Also, all revisions of the .cabal file will be available on the server. So OS packagers and maintainers can see it, and decide if they want to take the original or a revision. The reason I think a scheme like this will work is because it does work in other systems. For example in Gentoo they have ebuilds (much like .cabal files) and they version the ebuilds with an extra revision number, beyond that of the upstream package. Yes, the revision does need to be visible to users so that it doesn't confuse things. And that's where we will probably need some further work in the client, to make this info visible. And yes, there is an issue of how do we communicate fixed back upstream so they get incorporated into the next release. That's another management issue that's mostly a server side issue. So again, we'll work on the management issues on hackage, but having the client support the feature will make it easier and smoother introducing that. Duncan _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
