Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Improve tools to manage ad-hoc package releases #659

Open
bos opened this Issue · 0 comments

2 participants

@bos
Owner

(Imported from Trac #667, reported by @dcoutts on 2010-04-27)

Hackage is suited for major software releases by package maintainers. It is not suited to distributing betas, daily snapshots or random forks, or patches of existing releases.

For example a user may have some patch or bugfix for a package that they need. It takes time for maintainers to review and integrate these. Sometimes maintainers have little time, or they disagree with a patch approach or quality.

It is right that maintainers have control over what is released on hackage. However there is a need for decentralised, ad-hoc and short term releases. We do not want to encourage the pollution of the package namespace with lots of short-term forks.

One solution is to let users post package forks on their own webspace. We would want to extend cabal so that people can run:

cabal install http://code.haskell.org/~user/foo/foo-fork-to-fix-blah-1.0.1.tar.gz
This makes it very decentralised. We may want to add some feature to hackage package pages to link to third-party forks.

In addition to hosting and installing single packages it would be useful to be able to publish package collections. Of course this is exactly what a hackage archive is. We should provide easy tools to make and manage hackage archives that can be hosted on dumb http file servers.

Going one step further, the hackage index format should be extended to make it more RESTful by including links to tarballs rather than just assuming that tarballs are found relative to the index file using some fixed layout. This would allow people to publish indexes that span multiple servers. This gets close to the concept of a package "search path" promoted by the searchpath project (http://searchpath.org/).

Additonally, an index should allow us to point to source control repos rather than just to release tarballs. This kind of index would be useful for nighly builds.

@ttuegel ttuegel added this to the _|_ milestone
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.