A view with all tarballs as links #96

nomeata opened this Issue Sep 29, 2013 · 9 comments

4 participants


For Debian, we need a way to specify a so-called “watch file” for each package, which contains instructions on how to obtain the list of available versions and their tarballs. Previously, this file looked like

filenamemangle=s|(.*)/$|hakyll-$1.tar.gz|" \
    http://hackage.haskell.org/packages/archive/hakyll \

but this broke with hackage2 (The archive URL has gone).

Reading this information from, say, http://hackage.haskell.org/package/hakyll, is difficult, for example the current version is not a link there.

Therefore I’d like to suggest a new view, e.g.,
which contains a classical listing of all tarballs of available versions, as links. This would greatly simplify our watch file to something like

http://hackage.haskell.org/package/hakyll/tarballs .*\.tar\.gz

This should be reasonably easy to implement (just scan over the [PkgInfo] for tarballs, for a given package). Definitely sounds necessary. The ideal solution seems to be an Apache directory listing, which we don't have anymore :)

The main question is about maintaining this long-term. @dcoutts: Is /package/:package/tarballs the best place for this to go? Should it go into the Core feature, or a more distro-specific one?


As nomeata commented on IRC, it seems like the new URL scheme might also break Fedora. (see HACKAGE-DEFAULT, although I'm unclear about what the regex alias is): https://fedoraproject.org/wiki/Upstream_release_monitoring

Haskell member

Can you be a bit more specific about what Debian needs? There is already a standard url scheme for the tarballs, so is all you need a way to get a list of versions, or do those really have to be html links to tarballs?

If we can do something that makes sense generally then we can do that, otherwise we can just make something specific for debian. I'm not sure that the /package/:package/tarballs suggestion does make sense generally.

For Fedora it looks like we could make it work with a /package/:package/versions resource that contains a list of all the versions for that package name (as plain text, json, or html links). Hopefully that'd work for debian too.


Unfortunately, the tool Debian uses (uscan) is not very flexible; it assumes that there is one page, which contains links (which are recognizable by a regex, which is error-prone on the package overview page due to the description), one per version. Ideally the link goes directly to the tarball, but some mangling of the link’s href to fix that is possible (this was done using the current scheme). But then it hard-codes even more of the page layout and can break (as it has done now).

A /package/:package/tarballs view might not be super useful in general, you never know what people might use it for, and the implementation and maintenance burden would be low, so this would still be my preferred option.

If you really would like to leave this out of hackage I can probably hack up a tool that creates such pages somewhere else, and use that.


We already have a Distros feature, might be reasonable place to support distribution-specific views?

@nomeata nomeata added a commit that referenced this issue Sep 30, 2013
@nomeata nomeata Create a /packages/:pkgname/tarballs view
A simple view containing all tarballs of a package. Fixes: #96.
@nomeata nomeata added a commit that referenced this issue Sep 30, 2013
@nomeata nomeata Create a /packages/:package/tarballs view
A simple view containing all tarballs of a package. Fixes: #96.

I created a pull request, hoping that the discussion will stay shorter than the code diff, and to have something concrete to talk about.


Btw, one reason why this might go into a distro feature, but probably not the Distro feature, is because that feature is all about stable versions of packages in distros, whereas this is about upstream maintenance (much earlier in the pipeline, such that they are orthogonal from Hackage's point of view).

Haskell member

Ok, #108 was merged.

@dcoutts dcoutts closed this Oct 1, 2013

Just so that I can plan: When do you expect the change to hit the deployed hackage?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment