Gearing up for a cabal-install-1.16.0 release

[Duncan Coutts]

On 30 September 2012 05:26, Bryan O'Sullivan <bos at serpentine.com> wrote:
> On Fri, Sep 28, 2012 at 5:55 PM, Duncan Coutts
> <duncan.coutts at 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